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]
<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
<https://groups.google.com/group/pyglet-users>.
For more options, visit
https://groups.google.com/d/optout
<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
<https://groups.google.com/group/pyglet-users>.
For more options, visit https://groups.google.com/d/optout
<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
<https://groups.google.com/group/pyglet-users>.
For more options, visit https://groups.google.com/d/optout
<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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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 <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.
