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.
