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.
