What is the plan for handling files that contain multiple "sub-models" (for lack of a better term)? it's not unusual for 3D meshes to be segmented, and result in quite a few models at runtime
On Thu, 8 Jun 2017 at 07:29 Benjamin Moran <[email protected]> wrote: > Tristam, > > That would be fantastic. I'll get my work pushed to a branch on bitbucket > once I have a chance to clean it up a little bit, so you can see how it's > structured. If you want to start with a general parser, it'll be trivial to > turn it into a codec. > > So far, I have the following design points (which we can change as > appropriate of course): > > - The Model class is not fleshed out, and is little more than a > container for vertex lists. We can add approprite methods, reprs, etc. > later. > - The Models always uses a Batch. If none is passed in to > model.load(), the codec will create it's own batch and use that when making > it's vertex lists. (This is how the text module does it). > - There are two possible Groups that the codecs use, depending on the > mesh's material - TexturedModelGroup, and ModelGroup. > > > > > > On Thursday, June 8, 2017 at 12:54:36 PM UTC+9, swiftcoder wrote: > >> If you need a hand with glTF, give me a shout. I've writting a couple of >> implementations in my day :) >> >> On Wed, 7 Jun 2017 at 20:47 Benjamin Moran <[email protected]> wrote: >> >>> I think as one of the "pyglet elders", Richard gets two votes here :) >>> I believe that generic 3D model support, and a user-friendly way to set >>> 2D and 3D projections are two of the last things missing from pyglet. >>> >>> Splitting pyglet into seperate modules at this point is probably not a >>> good idea due to the aforementioned number of contributors. It's a >>> discussion best left for the future when we're migrated to GL3+/Python3, >>> and possibly pick up a few active contributors. In the meantime, to Steve's >>> point, I think we can definitely investigate tweaks to make pyglet's >>> modules more usable by themselves. I've seen others with similar complaints. >>> >>> Regarding avoiding bloat, I think the basic classes and loading >>> mechanisms are important. The codecs themselves are a different story, and >>> I agree that we shouldn't try to support too much. We have good mechanisms >>> for adding codecs later, just like the image module: >>> pyglet.model.codecs.add_decoders(MyFormatDecoder()) >>> model = pyglet.model.load("mymodel.xyz") >>> >>> One or two generic decoders are probably a good idea. Obj seems a >>> no-brainer. >>> Greg, I like the glTF format. I forgot all about that one. It seems like >>> there are plenty of tools to convert to it, and it's royalty free. >>> >>> >>> >>> On Thursday, June 8, 2017 at 8:09:20 AM UTC+9, Richard Jones wrote: >>> >>>> Careful, folks. Please don't kill off this actually very useful >>>> contribution to pyglet by sidetracking it into a massive (unnecessary, >>>> bordering on harmful in my opinion) refactoring. >>>> >>>> >>>> Richard >>>> >>> >>>> On 8 June 2017 at 03:36, Steve Johnson <[email protected]> wrote: >>>> >>>>> YES! As I was typing my last email I was considering breaking it down >>>>> explicitly like that, but decided to be vague instead. >>>>> >>>>> pyglet_core (gl, window, canvas, no dependencies) >>>>> pyglet_utils (event, clock, no dependencies) >>>>> pyglet_media (media) >>>>> pyglet_graphics (graphics) >>>>> pyglet_drawing (sprite, text) >>>>> pyglet_assets (resource, image) >>>>> pyglet_input >>>>> pyglet_transforms?? >>>>> pyglet_models?? >>>>> >>>>> And then tie it all together with the pyglet superpackage, which has >>>>> pyglet.app. >>>>> >>>>> You could also split the maintainer responsibility up across modules, >>>>> version them separately, and have clear API touch points between them. >>>>> They >>>>> could remain in the same repo to keep things simple. The docs could be >>>>> unified, or split up and linked using intersphinx, with the high level >>>>> guides living in the main pyglet repo. (Reading back over this paragraph, >>>>> though, that seems like too much overhead for the number of people on this >>>>> project.) >>>>> >>>>> The split would solve a problem I had recently: if you want to use >>>>> pyglet just for audio (in this case I was doing my graphics with >>>>> BearLibTerminal), you have to do some pyglet.options voodoo. I'd rather >>>>> just import pyglet_audio. It's the nicest way to do audio in Python by >>>>> far. >>>>> >>>>> On Wednesday, June 7, 2017 at 10:11:26 AM UTC-7, swiftcoder wrote: >>>>>> >>>>>> Yeah, that's fair. Maybe it's time that pyglet became a collection of >>>>>> libraries. >>>>>> >>>>>> On the other hand, we do need to overhaul pyglet itself to provide >>>>>> all the modern OpenGL primitives. And those primitives aren't very useful >>>>>> to newcomers without a high-level abstraction over models/scenes... >>>>>> >>>>>> Maybe go the other direction. Produce a pyglet-core with just the >>>>>> OpenGL primitives, and make pyglet itself a meta-package over >>>>>> pyglet-core, >>>>>> pyglet-scene, etc? >>>>>> On Wed, Jun 7, 2017 at 09:07, Steve Johnson <[email protected]> wrote: >>>>>> >>>>>>> I question the idea of including any of this stuff in pyglet. It is >>>>>>> already a large library. >>>>>>> >>>>>>> Why not start by creating a third party module, letting it stabilize >>>>>>> on its own, and rolling it into pyglet when it has proved its usefulness >>>>>>> and quality? >>>>>>> >>>>>>> Honestly, if I were designing pyglet from scratch, I would create >>>>>>> four separate libraries. Dependency management and app packaging in the >>>>>>> Python ecosystem are not as hard as they used to be. >>>>>>> >>>>>>> On Wednesday, June 7, 2017 at 8:29:11 AM UTC-7, swiftcoder wrote: >>>>>>> >>>>>>>> Gltf would be a natural choice, in many ways: >>>>>>>> >>>>>>>> https://github.com/KhronosGroup/glTF >>>>>>>> >>>>>>>> It's an open interchange format, with some degree of tool support >>>>>>>> (and very easy to write converters for). >>>>>>>> >>>>>>> On Wed, Jun 7, 2017 at 08:08, DR0ID <[email protected]> wrote: >>>>>>>> >>>>>>> On 07.06.2017 05:29, Benjamin Moran wrote: >>>>>>>>> >>>>>>>>> OK, loud and clear. I won't waste effort on transform methods. >>>>>>>>> >>>>>>>>> Another question is what types of codecs we should try to include >>>>>>>>> other than obj, and who wants to write them? :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wednesday, June 7, 2017 at 10:34:31 AM UTC+9, Richard Jones >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> There absolutely has to be a default vertex and fragment shader >>>>>>>>>> with this implementation, yep. >>>>>>>>>> >>>>>>>>>> On 7 June 2017 at 11:19, Tristam MacDonald <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I think it's going to end up actively harmful. >>>>>>>>>>> >>>>>>>>>>> We need to give them the tools to do GPU transforms anyway (a >>>>>>>>>>> class for placing models in the scene, default uniforms for the >>>>>>>>>>> transform >>>>>>>>>>> matrices, and a default vertex shader), at which point having >>>>>>>>>>> methods to >>>>>>>>>>> also pre-transform models on the CPU are redundant and/or confusing. >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 6, 2017 at 18:12, Benjamin Moran <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks for your feedback Tristam. I actually do agree with both >>>>>>>>>>>> of you guys that this is GPU/shader territory. >>>>>>>>>>>> >>>>>>>>>>>> I am mainly looking at it from the viewpoint of a user thats >>>>>>>>>>>> using Pyglet 1.3, and has little or no OpenGL knowledge. >>>>>>>>>>>> For example, I have a little side-scrolling shoot-em-up game I >>>>>>>>>>>> made to play around with projection and "2.5D" style side >>>>>>>>>>>> scrolling. Lets >>>>>>>>>>>> say I have a single asteroid model that I want to place in the >>>>>>>>>>>> background >>>>>>>>>>>> at various random positions and rotations. Having a few transform >>>>>>>>>>>> methods >>>>>>>>>>>> would let you randomly place them at runtime without needing to >>>>>>>>>>>> create a >>>>>>>>>>>> full scene in an editor. >>>>>>>>>>>> >>>>>>>>>>>> That's basically it. Do you think it would harmful to include >>>>>>>>>>>> transform methods, in the sense that we would be giving users >>>>>>>>>>>> tools that >>>>>>>>>>>> they probably shouldn't really be using anyway? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tuesday, June 6, 2017 at 11:45:13 PM UTC+9, swiftcoder wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure it's worthwhile to include *at all*. What's the >>>>>>>>>>>>> advantage of doing that, versus transforming the model on the GPU? >>>>>>>>>>>>> >>>>>>>>>>>>> Matrix * vector operations in the vertex shader are really >>>>>>>>>>>>> cheap, and most programs are limited by the fragment shader >>>>>>>>>>>>> performance. >>>>>>>>>>>>> >>>>>>>>>>>>> The only case where this might be a win is if you are >>>>>>>>>>>>> assembling a level from singular geometries at runtime. Which >>>>>>>>>>>>> seems a >>>>>>>>>>>>> vanishingly unlikely case - generally you would assemble static >>>>>>>>>>>>> elements in >>>>>>>>>>>>> your editor, and then add multiple copies of props, etc at >>>>>>>>>>>>> runtime. >>>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 6, 2017 at 00:29, Benjamin Moran < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ISTM that gross operations on the model (transformations on >>>>>>>>>>>>>>> all vertices like the translation - I think that's what you >>>>>>>>>>>>>>> mean by >>>>>>>>>>>>>>> "shifting the model") should be handled entirely by a shader, >>>>>>>>>>>>>>> and no actual >>>>>>>>>>>>>>> vertex data manipulation, since setting the shader variable >>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>> infinitely faster. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Richard >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, sorry, I do mean translation. And you're absolutely >>>>>>>>>>>>>> right that it's silly to do these types of transformations on >>>>>>>>>>>>>> the CPU in a >>>>>>>>>>>>>> realtime application. >>>>>>>>>>>>>> I was mainly thinking that it's useful to have transform >>>>>>>>>>>>>> methods to reposition static objects in the scene when you first >>>>>>>>>>>>>> load them. >>>>>>>>>>>>>> I think the only possibilities are passing arguments to the >>>>>>>>>>>>>> pyglet.model.load function, or doing it right after loading. If >>>>>>>>>>>>>> you do it >>>>>>>>>>>>>> after loading, the following three methods should cover most >>>>>>>>>>>>>> bases: >>>>>>>>>>>>>> Model.update(x, y, z) # Translate on a specific axis. >>>>>>>>>>>>>> Model.scale(1.0) # Rescale the entire model. >>>>>>>>>>>>>> Model.rotate(x, y, z) # Rotate along one or more axis. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This would come with a big fat warning about not doing this >>>>>>>>>>>>>> every frame, and of course using shaders is going to be >>>>>>>>>>>>>> necessary for most >>>>>>>>>>>>>> things. >>>>>>>>>>>>>> Does that sound reasonable? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>>> Google Groups "pyglet-users" group. >>>>>>>>>>>>>> >>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Visit this group at >>>>>>>>>>>>>> https://groups.google.com/group/pyglet-users. >>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "pyglet-users" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>>>>> . >>>>>>>>>>>> Visit this group at >>>>>>>>>>>> https://groups.google.com/group/pyglet-users. >>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "pyglet-users" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>>>> Visit this group at https://groups.google.com/group/pyglet-users >>>>>>>>>>> . >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "pyglet-users" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi there >>>>>>>>> >>>>>>>>> Not sure if you would like an external dependency or not, but >>>>>>>>> there is assimp, see >>>>>>>>> >>>>>>>>> http://www.assimp.org/index.html >>>>>>>>> >>>>>>>>> It loads various formats to the same structure so the code will >>>>>>>>> only have to worry about one format internally (I haven't used it >>>>>>>>> yet, but >>>>>>>>> probably will try it out in future). >>>>>>>>> >>>>>>>>> And I don't see the point to write your own codecs if some one >>>>>>>>> else already has gone through the trouble making such a library. >>>>>>>>> >>>>>>>>> But sure, pyglet could focus on just one or few formats and that >>>>>>>>> would be probably enough (since there are other ways to convert a >>>>>>>>> model to >>>>>>>>> the supported format). I would like a format where one can define >>>>>>>>> bones and >>>>>>>>> animations too. But that is just my wish. >>>>>>>>> >>>>>>>>> Keep up the good work. >>>>>>>>> >>>>>>>>> ~DR0ID >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "pyglet-users" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "pyglet-users" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "pyglet-users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "pyglet-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/pyglet-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/pyglet-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
