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.
