Hi John,
Hi,
I am compiling some code with the current git repository version of OSG and found that
State's "getGLBeginEndAdapter" has been removed. Looking through the history,
I see this happened at: commit e11e45a2e36de91bbe956223c43e8c5a50f9b72b.
The comment is only "Removed GLBeginE
Hi Nabil,
Hello,
I'm using geometry shader with OSG to do some operations on mesh using GPU.
When i use /triangles_adjacency/ in the input layout, my shader crashes.
I tried with /layout(triangles) in/ and it's running well.
Is there any configuration in OSG that i should use, or a pre-proce
Hi John,
The GLBeginEndAdapter was an interim solution while older parts of the OSG
were migrated over to using vertex arrays and DrawArrays/DrawElements, once
this migration work was completed the core OSG no longer required it, so I
removed it to avoid bloat. This migration work was required as
Thank you Sebastian. So If i set the DrawArrays mode of the PrimitiveSet,
does it suffice?
Otherwise, is it easy to implement? Sorry but i'm newby in OSG.
On 21 July 2017 at 09:36, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:
>
>
> Hi Nabil,
>
>> Hello,
>> I'm using geometry s
Hi Nabil,
Thank you Sebastian. So If i set the DrawArrays mode of the
PrimitiveSet, does it suffice?
Otherwise, is it easy to implement? Sorry but i'm newby in OSG.
Can you elaborate on this?
Usually you need to set the program-parameter for output:
GL_GEOMETRY_INPUT_TYPE and simply pass yo
Hi All,
I build a huge geometry (27 milion vertices, 9 milion triangles) as follows:
osg::Geometry* geometry = new osg::Geometry;
geometry->setDataVariance(osg::Object::DYNAMIC);
geometry->setVertexArray(buildVertices(count));
geometry->setColorArray(buildColors(cou
I don't know about the double frame but the default for geometries
(drawables in fact) is to use OpenGL display lists (depending on the OSG
compilation).
OpenGL display lists creation takes time. The dirtyDisplayList method
forces OSG to re-create the OpenGL display list.
The solution is to
Hi Gianni,
As Lionel explains if you have display lists enabled (they are by default)
then rebuilding the display list will create a big cost. Not using display
lists will avoid this one off cost, but it will increase the cost of
rendering on some drivers.
However, I would recommend you take a s
Thanks Lionel and Robert for the quick reply.
I tried what Lionel suggested but in fact the geometry generation is much more
slow now.
Anyway, since I suspected that "dirtyDisplayList()" is the cause of the delay,
I tried to remove that line but without it I cannot see the new color.
Now, is "di
If you use display lists, you have to tell OSG that it has to re-build it.
If you use vertex arrays, colors->dirty() should be enough.
On 21/07/2017 12:32, Gianni Ambrosio wrote:
Thanks Lionel and Robert for the quick reply.
I tried what Lionel suggested but in fact the geometry generation i
Hi Gianni,
On 21 July 2017 at 11:32, Gianni Ambrosio wrote:
> I tried what Lionel suggested but in fact the geometry generation is much
> more slow now.
> Anyway, since I suspected that "dirtyDisplayList()" is the cause of the
> delay, I tried to remove that line but without it I cannot see the
Hi Lionel,
thanks for the explanation. So, that information is stored into the DL.
On the other side I can confirm that the color is updated correcly without
"geometry->dirtyDisplayList()" if DL is not used. But unfortunately, for huge a
geometry, creation is extremely slow (the example applicat
Thank you very much Robert,
I will do as you suggested.
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=71302#71302
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.op
13 matches
Mail list logo
