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] <javascript:>>
> 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].
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.
