I hacked on this a bit more, and basically have a working implementation now. It's structured pretty much like the image module, which I think makes the most sense after all. There is a single codec, which is wavefront (obj) decoder based on the pyglet/contrib/model code. It works, but needs major cleanup.
Richard, what would you say are vital method to have on the Model class? So far, I have a draw method (which people shouldn't use anyway), and an update method which allows shifting the model on one of the x, y, z axis (requiring lots of list slicing). Any thoughts on what methods would be most important to add? My personal use case is mainly for static background objects, so I'm not the best judge in this case! On Thursday, June 1, 2017 at 8:23:57 AM UTC+9, Richard Jones wrote: > > LGTM > > On 31 May 2017 at 18:03, Benjamin Moran <[email protected] <javascript:>> > wrote: > >> I quickly mocked something up that's based on the image module. One thing >> I'm not sure about is how to handle the API for passing in batches. >> >> The image module is: >> image = pyglet.image.load("image.png") >> # and: >> image = pyglet.resource.image("image.png") >> >> I currently doing this for the new model module: >> teapot = pyglet.model.load("teapot.obj", batch=batch) >> # and: >> teapot = pyglet.resource.model("teapot.obj", batch=batch) >> >> Instead of an Image, you'll get a Model instance back. This instance will >> have similar methods to the Sprite class, as much is appropriate. >> Does that look reasonable? >> >> -Ben >> >> >> On Tuesday, May 30, 2017 at 3:39:12 PM UTC+9, Richard Jones wrote: >>> >>> On 30 May 2017 at 16:08, Benjamin Moran <[email protected]> wrote: >>> >>>> I use these clases here for my personal 2D and 2.5D (3D, but only ever >>>> viewed from straight on) projects: >>>> https://bitbucket.org/snippets/HigashiNoKaze/7ndxM >>>> >>>> It might work to have a Projection class with set and unset methods, >>>> which could be passed to the Window. This could be called automatically >>>> before and after draw. One issue is that sometimes you might want to reset >>>> this stuff during a draw call, such as for doing a 2D hud over a 3D >>>> background... >>>> >>> >>> Modern Python techniques suggest a context manager (or set of related >>> context managers that could be used individually or combined) that >>> pushes/pops state :-) >>> >>> >>> >>>> As for the actual 3D model transformations, I suppose it makes the most >>>> sense to put the transform calls inside a ModelGroup (based on how the >>>> Sprite class does it with SpriteGroup). This would allow setting any >>>> transform variables (x, y, z) on the model, and having it handled when the >>>> Group sets the state. >>>> >>> It would be foolish to try to recalculate all of the Model's vertex >>>> lists to move it, but it might be useful to have a base offset parameter >>>> for when the image is loaded. This would allow loading in multiple models >>>> that are all based around 0, 0, 0, but you want to situate at different >>>> positions within the scene. >>>> >>> >>> Perhaps attach some GLSL to the model to handle transformation? >>> ModelGroup etc. then just loads the vertices etc. and manages the GLSL >>> variables. >>> >>> >>> Richard >>> >>> -- >> 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.
