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.
