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