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