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