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] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
