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 <benmora...@gmail.com> 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 <dio...@gmail.com> 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 <dio...@gmail.com> 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 <dr0id...@gmail.com> 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 <swift...@gmail.com>
>>>>>>>> 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 <benmo...@gmail.com>
>>>>>>>>> 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 <benmo...@gmail.com>
>>>>>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>>>>>>>>> To post to this group, send email to pyglet...@googlegroups.com
>>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>>>>>>> To post to this group, send email to pyglet...@googlegroups.com.
>>>>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>>>>>> To post to this group, send email to pyglet...@googlegroups.com.
>>>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>>>> To post to this group, send email to pyglet...@googlegroups.com.
>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>>>> To post to this group, send email to pyglet...@googlegroups.com.
>>>>>>> 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 pyglet-users...@googlegroups.com.
>>>>> To post to this group, send email to pyglet...@googlegroups.com.
>>>>> 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 pyglet-users...@googlegroups.com.
>>> To post to this group, send email to pyglet...@googlegroups.com.
>>> 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 pyglet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to pyglet-users@googlegroups.com.
> 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 pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
