Back to the pyglet.model module, I've been playing with some things in order to find out a generic way to structure the base classes. I ended up with "Material" and "Mesh" classes. The Mesh class contains vertex points and one (on none) Material attributes. The Model class is passed a list of Meshes, which are then finally turned into pyglet vertex lists on instantiation. It's probably easiest to understand just by looking at the code in the pull request: https://bitbucket.org/pyglet/pyglet/pull-requests/108/3dmodel/diff We essentially end up with one Group per mesh in the Model class, but these groups will be consolidated if possible when adding to the Batch.
I'm not 100% sure if this is flexible enough to handle the needs of other formats besides obj, so hopefully someone can comment here. Perhaps writing an additional decoder for another format will make this clear. For the Model class, it will need a smooth mechanism for updating it's Groups. Models will tend to have multiple groups if they are complex, and in the future a Group can contain a Shader. Having an easy way to view and change these seems important. On Friday, June 9, 2017 at 12:16:20 AM UTC+9, Tristam MacDonald wrote: > > 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] > <javascript:>> 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] <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.
