Hi all,
As said in my post (a few minutes ago), it sounds like we do not all agree on
what is a primitive!
OpenGL says a primitive can be a strip/fan (
http://www.opengl.org/wiki/Primitives ).
However, I agree it sounds very strange to have same behaviour for
BIND_PER_PRIMITIVE and
Primitive because I had the feeling that it can have slightly different
semantics in OpenGL docs and different in Performer docs and different in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users
Primitive because I had the feeling that it can have slightly
different
semantics in OpenGL docs and different in Performer docs and different
in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users
Hi Sukender,
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
it is my understanding that OpenGL can only do BIND_PER_VERTEX natively.
There is no such thing as a face normal or color. There is only
OVERALL means the same attrib (normal/color) for all primitive sets in
geometry.
Why change that ?
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:59 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Allright. So
primitive sets in
geometry.
Why change that ?
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:59 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Allright. So what about changing the terms we use? Say
Hi Wojtek and Frederic,
Indeed, it seems OpenGL natively reads per vertex normals, by checking the
current normal value (given with glNormal()). And when looking at
glShadeModel(), it says which vertex normal is used when doing GL_FLAT
lighting (roughly: the last vertex of the
On 01/09/2011 05:37 AM, Wojciech Lewandowski wrote:
Well... what you write sounds like you don't agree with me, because I
postulate that that BIND_PER_PRIMITIVE should differ from
BIND_PER_PRIMITIVE_SET and BIND_PER_VERTEX. And yes I will say that again,
its possible to make faceted apperance
On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote:
Hi, Sukender,
I think we fully agree both on whats a 'Primitive' and binding
interpretations.
I don't think we agree at all...
man glBegin
NAME
glBegin, glEnd - delimit the vertices of a primitive or a group
of like
Yes, Jason. This is why I proposed to have a BIND_PER_ELEMENT, which would do
per triangle/quad (since OpenGL says a strip is a primitive). Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Jason Daly jd...@ist.ucf.edu a écrit :
On
Hi Guys,
For reference on this discussion, non of BIND_PER_PRIMITIVE or the
proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES,
the old BIND_PER_PRIMITIVE is very much deprecated and only kept
around for backwards compatibility.
Given even BIND_PER_PRIMTIIVE is deprecated there
Sorry, I'm skipping around a lot. Not sure why I'm not getting a single
thread here...
On 01/10/2011 05:52 AM, Wojciech Lewandowski wrote:
Hi Sukender,
What for ? If we agreed on Primitive meaning a single Triangle from
TriangleStrip then we don't need to change the enums. Current binding
avoided using
this word before. Besides, I am not native speaker so I would rather shut my
mouth and don't talk more about this
Silent Cheers,
Wojtek Lewandowski
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 5:06 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users
On 01/10/2011 11:26 AM, Robert Osfield wrote:
Hi Guys,
For reference on this discussion, non of BIND_PER_PRIMITIVE or the
proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES,
the old BIND_PER_PRIMITIVE is very much deprecated and only kept
around for backwards compatibility.
Hi all,
Yeeek... think I'm gonna BIND_PER_VERTEX+GL_FLAT finally! ;p
Joking apart, I agree with the fact it's deprecated and should just stick with
OSG 2.8 bahaviour.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Jason Daly jd...@ist.ucf.edu a
Hi Robert, Jason,
I am lazy guy, and I agree with both of you, its only neccessary to make it
backward compatibile ;-)
However, for purely academic reasons I will respond to Jason. But don't
treat my post as call for revolution. Its just my opinion how PER_VERTEX,
PER_PRIMITIVE,
Hi All,
Perhaps we should be asking the question what was the behavior prior
to the refactor to I did for GL3/OpenGLES support. Sukender did your
Geometry work previously? Is this a regression or just a behaviour
that you weren't expecting?
Robert.
On Fri, Jan 7, 2011 at 10:04 PM, Wojciech
On 1/8/2011 6:19 AM, Robert Osfield wrote:
Hi All,
Perhaps we should be asking the question what was the behavior prior
to the refactor to I did for GL3/OpenGLES support. Sukender did your
Geometry work previously? Is this a regression or just a behaviour
that you weren't expecting?
Good
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not use it!
;) ). When having TRIANGLE_STRIP, with normals per primitive, I got one normal
per triangle strip, whereas OpenGL seem to say I should have one normal per
triangle. Am I wrong?
The geometry looks
Hi again,
About my problem with triangle strips (see below), I found something strange in
Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS):primLength=1; break;
case(GL_LINES):
Hi Sukender,
Do you an online reference to confirm the interpretation of per
primitive binding when using triangles and quad strips?
It does sound like your suggestion of adding GL_TRIANGLE_STRIP and FAN
to the switch statement setting the primitive length might be
appropriate. Could you
Thanks for your answer Robert.
About sources, I do not have (yet) an official source, but only a large bunch
of forums/discussions saying the same thing. I'd like to find a more reliable
source of info before starting.
And of course I can do it, but unfortunately not soon (= a few days).
= If
Hi Sukender,
About sources, I do not have (yet) an official source, but only a large bunch
of forums/discussions saying the same thing. I'd like to find a more reliable source of
info before starting.
And of course I can do it, but unfortunately not soon (= a few days).
= If anyone knows
On 01/07/2011 10:52 AM, Jean-Sébastien Guay wrote:
I don't have reliable info to add, but I wonder 2 things:
First, does OpenGL interpret one primitive as one draw call (= one
*PrimitiveSet*) ? If so, then that's your answer, BIND_PER_PRIMITIVE
would mean one normal for the whole triangle
On 01/07/2011 11:33 AM, Jason Daly wrote:
I suppose you could change the normal in the middle of the strip with pure
OpenGL, but I
have no idea what it would end up looking like (might have to check an
older spec for that). My guess is that it wouldn't be what you're
looking for, though.
Hi, Jason
I generally agree with your post that binding per primitive is a scene graph
thing, but I would disagree with such BIND_PER_PRIMITIVE interpretation:
BIND_PER_PRIMITIVE is a scene graph thing, it has nothing to do with pure
OpenGL. All BIND_PER_PRIMITIVE means is this:
Hi Robert,
I am now able to set an overall color for otherwise uncolored
geometries with your suggested fix. I still don't understand why this
is correct. I thought that the setStateSet would set a current color
from it's material which is now OSG seemed to behave until 2.9.3.
osg::Group
On Wed, Sep 22, 2010 at 7:13 PM, Don Leich d...@ilight.com wrote:
Hi Robert,
I am now able to set an overall color for otherwise uncolored
geometries with your suggested fix. I still don't understand why this
is correct. I thought that the setStateSet would set a current color
from it's
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can
I confirmed that the bug persists in today's SVN trunk. In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
-Don
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi J-S,
I'm using TortoiseSVN on a Windows system. This has a right-click
menu entry for SVN Checkout. The GUI can only handle the URL
and was confused by the spaceOpenSceneGraph after trunk.
You're exactly right that I was pulling down and eternity and a half.
Today, after contemplating
Hi Don,
I'm using TortoiseSVN on a Windows system. This has a right-click
menu entry for SVN Checkout. The GUI can only handle the URL
and was confused by the spaceOpenSceneGraph after trunk.
Heh, that's the destination directory when using the command-line SVN...
So you're right, in
Hi Don,
This is clearly a bug, could you try the svn/trunk version of the OSG
to see if it's still present? If so could you provide an .osg file
that reproduces the problem?
As a general note, BIND_PER_PRIMITIVE is bad for performance and
portability, it's there for convenience of backwards
Hi Robert,
I bailed on my svn import. TortoiseSVN wouldn't work with the checkout
command as documented. I got the checkout going, but I seemed to be getting way
more than I wanted. After more time than I had to spend I still didn't
have the OSG source.
I did manage to produce a test file.
Hi Don,
I bailed on my svn import. TortoiseSVN wouldn't work with the checkout
command as documented. I got the checkout going, but I seemed to be
getting way more than I wanted. After more time than I had to spend I
still didn't
have the OSG source.
What command did you try?
This page gives
I know it's slow, but we'd been using BIND_PER_PRIMITIVE mainly for
backward compatibility for faceted shading and coloring occasionally.
After our recent upgrade from osg-2.8.3 to 2.9.8 everything rendered
with BIND_PER_PRIMITIVE is wrong -- bad colors or material properties
ignored. Is this
36 matches
Mail list logo
