Looks like a missing include. Try adding an #include to the top of
that file.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62672#62672
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Robert,
> OpenGL doesn't provide any capability query system without first opening a
> graphics context... which means the OSG can't provide anything similar.
Are you sure about this? The Ogre3D engine implements such a query feature for
multisampling levels, not requiring a graphics window
Hi,
In the osgreflect example a ClipNode is used to remove unwanted objects
"behind" the reflection. Is there a way that in addition to clipping these
objects, we could also cull them? Objects that are entirely behind the
reflection obviously do not need to be rendered. From what I could tell i
I have implemented the CullCallback way and it seems to work great. Thanks for
the tip!
Cheers
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63322#63322
___
osg-users mailing list
osg-users@
Thanks for sharing your changes Trystan! Always good to have more choices with
regards to video plugins. FWIW, I have another very stable FFmpeg plugin here:
https://github.com/scrawl/ogre-ffmpeg-videoplayer
It's currently using Ogre for rendering rather than OSG, but should be really
easy to p
Hi OSG friends,
A common challenge for OSG users are the implications of the viewer threading
model - by default the viewer.frame() will return before the draw dispatch is
complete, meaning users (and the OSG) can start preparing the next frame before
the current frame has completed. However, i
Hi Robert,
Thanks for the hints - I am using a release build, and I already disabled
double precision from cmake which gave me another nice boost.
In the stats handler I am seeing roughly the same amount of time spent in the
cull, draw and GPU threads. After adding the double buffering the 3 th
> I am surprised you saw a boost with disable double precision. What specific
> element you do you change w.r.t double precision?
I enabled OSG_USE_FLOAT_MATRIX and OSG_USE_FLOAT_PLANE and observed a 10%
framerate improvement.
Might be related to particle systems, which I forgot to mention I
Hi,
I get random crashes when recreating VBOs in my app. I managed to isolate the
crash into a small reproduction case.
Basically I have a cull thread filling in draw commands with VBOs, and the draw
thread executes them. Recreating the VBOs is what makes the crash appear.
Code:
#include
#
I solved it, see osg-submissions:
http://forum.openscenegraph.org/viewtopic.php?p=63652#63652
Cheers, Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63653#63653
___
osg-users mailing list
osg
Hi filnet,
>
> Code looks like this
>
> But I still get the invalid enumerant error followed by a crash.
>
there is one missing step in your code - you said you have a detached subgraph.
The OSG does not hold any pointers to detached subgraphs, so it can't do the
cleanup on its own. Only
Hi,
I'm running the osgshadow example and noticed that no extra cameras (beside the
main one) are to be seen in the stats handler.
Why is that?
I'd assume the light's view point is essentially a Camera, so why not handle it
as one? Assigning a separate cull thread to each shadow map (with the
Hi,
I was playing around with threading models today and found something odd.
For the sake of experiment, I used a osgViewer with a master camera, a slave
camera using the same graphics context as the master camera, and the
CullThreadPerCameraDrawThreadPerContext threading model.
I found that
Hi Robert,
I tried my application using the latest trunk and didn't notice any functional
regressions.
However, I did notice a performance decrease in the Update phase of about 20%,
compared to OSG 3.2.0. This had me a bit concerned, so I digged through the
changes and found commit
https://gi
Here's the profiling data...
apply this change to osgclip.cpp:
Code:
diff --git a/examples/osgclip/osgclip.cpp b/examples/osgclip/osgclip.cpp
index 3b74bd2..b202e35 100644
--- a/examples/osgclip/osgclip.cpp
+++ b/examples/osgclip/osgclip.cpp
@@ -28,6 +28,8 @@
#include
#include
+#include
+
Hi again,
I just noticed that what I need to achieve is actually quite simple: the
dynamicObjectRenderingCompletedCallback needs to be called from the culling
thread, rather than the drawing thread. This would ensure the next frame can
commence when the culling phase has ended, rather than comm
Hi,
Recently I have had my application tested on a wide range of linux
distributions. Some users are running into a problem with Qt version mismatch.
My application gets built with Qt4, but osgQt might be built with Qt4 or Qt5.
If you load Qt4 and Qt5 libraries in the same executable, a crash e
Hi Jan,
> The only way you could have problems is if you rely on the OSG
> libraries shipped by the distro, where you don't have control over how
> it was compiled.
That is precisely what's going to happen. My application is likely to become
available in distro repositories (FWIW, an older
Hi,
>
> You just have to build OSG twice using each version of Qt in turn. OSG
> respects the DESIRED_QT_VERSION already.
>
> cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
> cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series
>
Yes, but then you won't be able to install those two OSG versions at
Hi,
as a first step to rectify the problem I have introduced a version check within
osgQt (include/osgQt/Version) to store the Qt version that osgQt has been
compiled against. If there is a version mismatch, the build process will abort
with an #error rather than crashing at runtime later on. W
Hi Robert,
that's certainly an option, and it seems like the option that would place the
least burden on developers. I like the idea.
Counting the lines of code in osgQt we have just under 2000 lines in
implementation files, having that much code in headers shouldn't be too much of
a problem.
On second thought, I'm not sure how this solution would interact with the MOC
(QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning
the MOC needs to run on it and produce an object file. If we move all code to
the headers, then it would fall on the users responsibility to
Hi,
I seem to have hit the same problem. Texture slots 0-3 work fine, 4 and up
don't show.
To reproduce is very simple, you change the osgbillboard example to bind to
texture slot 4.
Code:
diff --git a/examples/osgbillboard/osgbillboard.cpp
b/examples/osgbillboard/osgbillboard.cpp
index a62
Oops, posted wrong code - that should have been 4 instead of 3, of course.
Code:
diff --git a/examples/osgbillboard/osgbillboard.cpp
b/examples/osgbillboard/osgbillboard.cpp
index a6243e8..64f893c 100644
--- a/examples/osgbillboard/osgbillboard.cpp
+++ b/examples/osgbillboard/osgbillboard.cpp
@
Hi Farshid,
> Are you sure the non-OSG based app was using the fixed function pipeline?
Ah, that's most definitely it. Yes, I was using shaders before. I totally
forgot there were separate limits for fixed-function and shader texture units.
Thanks for the help,
Jannik
--
Read
Hi Gianluca,
> The _attributeMap actually contains as MATERIAL attribute exactly the pointer
> to the osg::Material property that I created.
> But in the attribute stack it appears as the ‘last_applied_attribute’, and
> ‘changed’ is set to true.
> For all other attributes the pointers stored
Hi,
AFAIK all OSG applications must link to OpenThreads. Even if you are not using
it directly, you might be calling an inlined OSG function that uses OpenThreads.
Are you using CMake in your project? If you do, then
${OPENSCENEGRAPH_LIBRARIES} should include the OpenThreads library by default.
> If I use m_SkyNode.release(), the memory increases again and again.
>
The release() function unassigns the pointer, but without freeing it (see the
function documentation). What you want instead is
Code:
m_SkyNode = NULL;
You seem to be fairly confused about the concept of shared poi
Looks like you aren't showing us the whole code. I don't see a removeChild in
the attached file.
In general, when removing a node you need to remove it as child of its
particular parent(s) (which is not necessarily the root node).
Code:
while (node->getNumParents())
node->getParent(0)->re
The MatrixTransform you are creating isn't actually in the scene graph.
What you have now is:
Root -> (some parent) -> Node
as well as a completely detached graph that won't have an effect.
MatrixTransform -> Node
What you need instead is:
Root -> (some parent) -> MatrixTransform -> Node
Hi Paolo,
> On a related topic, is there a way to query how many screens are available?
>
Try this:
Code:
unsigned int numScreens =
osg::GraphicsContext::getWindowingSystemInterface()->getNumScreens();
Cheers,
Jannik
--
Read this topic online here:
http://forum.opensc
This might be simply a driver limitation. Not all hardware and drivers support
multisampling. For example, I'm using OSG on Mesa + Intel HD Graphics which
doesn't support multisampling at all.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64858#6
Hi,
How is one supposed to use a custom StateAttribute?
The docs say that:
"When extending the osg's StateAttribute's simply define your own Type value
which is unique, using the StateAttribute::Type enum as a guide of what values
to use"
As it is, returning a unique value simply isn't possib
Hi Sebastian,
You may be interested in this topic, where I discuss some workarounds to
setting objects to DYNAMIC:
http://forum.openscenegraph.org/viewtopic.php?t=14849
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65408#65408
_
Hi OSG friends,
I will be wrapping up my OpenMW port to OpenSceneGraph soon and wanted to share
a few things with you that I learned along the way. One such thing is the
lighting system that I wrote. If you do a quick search on the mailing list, you
will see that the OpenGL fixed pipeline suppo
Hi Chris,
Thanks for the comment. From what I can tell, Forward+ is the same technique
that I'm doing, except that it uses grid culling to accelerate the building of
light lists. This will give you a performance boost in scenes with thousands of
lights, but isn't necessary otherwise. For me the
Hi Robert,
I have just noticed that approach of adding culling planes doesn't work 100%
accurately. Some meshes that have their bounding box fully outside of the
culling plane don't get culled.
To test with please check the attached osgreflect.cpp. I added a culling plane
so that everything ab
Oops, wrong file. Use this one please.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65432#65432
/* OpenSceneGraph example, osgreflect.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and ass
Hi,
The interaction of CullingSet, CullStack and CullVisitor is really confusing to
look at, but I think I have a lead!
It seems like the added frustum plane is reset right here:
https://github.com/openscenegraph/osg/blob/master/src/osg/CullStack.cpp#L214
when the cull visitor applies a transf
Ok, setting on projectionCullingStack works fine for the whole subgraph, you
just have to transform the plane to view space first:
Code:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
Hi Nick,
the particle template's velocity isn't used, it's the particle emitter that
determines initial particle velocity. Have a look at the ModularEmitter /
Shooter classes in osgParticle.
If you wanted to globally make particles simulate faster (as in a time lapse)
you could just change the
Hi,
I noticed that the git mirror at https://github.com/openscenegraph/osg hasn't
been updated in a few weeks. It's still at r15151 while the svn is at r15172.
Is there a problem?
I found the mirror really useful for looking at changes, as well I used git to
prepare all my patches, so hopefull
Hi Tobias,
The texture matrix is a fixed function state that may not have an effect when a
shader is used. To get the desired effect, the shader code needs to get the
texture matrix via gl_TextureMatrix built in variable and then multiply the
texture coordinates with it. I presume the osgFX::Bu
There is a very high number of PrimitiveSets in your screenshot. In fact you
seem to have roughly one PrimitiveSet per 4 vertices, that is ridiculous. Each
PrimitiveSet needs an OpenGL draw call to render it. Try reorganizing your
models to use as few PrimitiveSet's as possible.
---
Hi,
The LineSegmentIntersector creates NaN warnings when applied to a node with
zero scale. I've attached a 3 line change to osgintersection.cpp to reproduce
the issue.
The NaN's first pop up when OSG tries to invert a zero matrix here:
https://github.com/openscenegraph/osg/blob/master/src/osg
Hi,
There is already a submission addressing this, but it wasn't merged yet.
http://forum.openscenegraph.org/viewtopic.php?t=15401
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65731#65731
___
Hi Pierre-Jean,
put your objects in the SORT_FRONT_TO_BACK render bin.
stateset->setRenderBinDetails(binNumber, "SORT_FRONT_TO_BACK");
Ensure that this particular binNumber is only used for objects you want sorted
front to back, so that the render bin can be created correctly.
The render bin
You can work around the issue using ScreenIdentifier::readDISPLAY() and passing
that ScreenIdentifier to WindowingSystemInterface::getNumScreens()
Code:
osg::GraphicsContext::ScreenIdentifier si;
si.readDISPLAY();
windowingSystemInterface->getNumScreens(si);
Hi Robert,
> I merged what were supposed to be "fixes" to the OpenThreads from a user
> submissions between OSG-3.2 and 3.4. The change in behaviour might stem from
> this, try reverting these changes and see what happens.
>
the setting of thread affinity for the main thread in
ViewerBase
Hi,
I have just tracked down a memory leak regarding FBO's to what appears to be an
OSG bug. Please check out the attached screenshot of gDebugger, OSG attempts to
glDeleteFramebuffers / glDeleteRenderbuffers from the main thread with no
context current. That can't work properly and I'm actuall
Hi Robert,
The leak is only noticable when you frequently remove and re-create cameras,
something that osgprerender does not do.
I've added an osg::Observer to test that the Camera is being deleted properly,
and it is. It looks like CPU side everything is being deleted correctly, only
on GPU s
One more thing, it does look like an FBO specific issue, because if I run with
./osgprerender --window
there is no leak whatsoever.
Thanks,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66210#66210
___
Hi,
Today I've been getting emails like this:
Code:
donotre...@secureserver.net
We received your inquiry
We received your inquiry
Your inquiry has been received. You should expect a response within 72 hours.
This is your Incident ID: 28748198
Thanks,
Customer Service
Please do not reply to
Hi,
osgViewer is what dispatches updates to the scene graph, fires off cull and
rendering, manages the camera, and abstracts the platform-specific graphics
context creation routines, among other things. You could bypass osgViewer if
you implemented these tasks yourself, but I imagine it would b
> I did it in a simpler way by adding a node at the end of the scenegraph and
> set a cullcallback and it works
Yes, that should work. You could also set a cull callback on the root node, and
in the callback do this:
traverse(node, nv); // cull scene root
// end of cull traversal
--
Hi,
The camera manipulator (which sets the main camera's view matrix) is updated at
the end of the update traversal. So, you need to make sure your sync code runs
after the update traversal and not before - else you'll be working with the
last frame's data which is probably what's introducing t
Hi Robert
Actually there is a bug here. The ShaderComposer::releaseGLObjects does not
override because it is declared without the const specifier.
Object::releaseGLObjects is declared const.
> osg::Object::releaseGLObjects is virtual, but
> osg::ShaderComposer::releaseGLObjects is not. Is the
Hi,
Good point, but I think there's more to it than just performance. There are
games using off-the-shelf scene graphs, for example Bethesda RPG games (Elder
Scrolls, Fallout) are built on Gamebryo, which is a general purpose scene graph
much like the OSG. (Note Gamebryo is a bit more than just
Hi,
I confirm that your example crashes. I actually reduced the code even further
and still got a crash:
Code:
#include
#include
#include
int main()
{
osg::ref_ptr foo = new osg::Group;
foo->addChild(new osg::Group);
std::cout << "foo has " << foo->getNumChildren() << " children" <
Hi,
turns out that my error was caused by mismatched OSG headers / libs. I had a
LD_LIBRARY_PATH in my .bashrc that pointed to a different OSG installation than
the one in /usr. Could you double check what libraries your executable is
linked against. To do so run:
Code:
ldd ./executable
Ex
Hi,
Actually the docs are correct, since OSG version 3.4 Drawable does inherit from
Node. It seems that you might have a version older than 3.4 locally.
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67035#67035
__
Hi Andrew,
the computeBound() does not respect node masks. In theory it would be possible
to skip the bounds update for nodes that were filtered by the cull mask, but
implementing this would get complicated quickly - you have to consider there
may be different cameras with different masks, mayb
Hi,
There may be some memory allocations left in the graphics driver. OSG does all
the OpenGL work from a background thread, so the memory used by OpenGL can not
be reclaimed immediately upon removing the node from the scene. Try calling
frame() a few times and then see if your memory usage dec
Hi Robert,
by fixing the author names you have essentially re-written the repository
history. This means that everyone who submitted pull-requests in the past will
have to manually rebase their changes on top of the new history. But it's not
so difficult to do that if you know how to use the gi
Hi Robert,
I haven't finished building yet, but right off the bat I get about a million of
these warnings:
Code:
/home/scrawl/Dev/osg/include/osg/Vec3us:34:58: warning: declaration of ‘g’
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec4f:46:9: warning: declaration of
Hi Robert,
Thanks for fixing the warning.
Just let you know, I did a build of OpenMW against OSG 3.5.3 and did not
encounter any build- or runtime problems.
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67368#67368
_
Hi Philipp,
>
> Also, Im having the issue that my drawCallback is only executed during the
> first frame and then skipped. Ive disabled culling and depth testing.
>
You need to disable display lists on your drawable. With display lists enabled
it will only draw once and then use the display
Hi,
Indeed, the depth attribute is the way to go. You also need to set a high
RenderBin number to make sure that the object you don't want occluded is always
rendered last:
Code:
mygeometry->getOrCreateStateSet()->setAttributeAndModes(new
osg::Depth(osg::Depth::ALWAYS), osg::StateAttribute::
Hi,
Unfortunately OpenGL doesn't support getting the supported version without
creating a context first.
https://gamedev.stackexchange.com/questions/28451/how-do-i-properly-check-if-a-particular-opengl-version-is-available
https://stackoverflow.com/questions/12184506/why-does-glgetstringgl-vers
Hi,
A Camera does not inherit the render target implementation, it will simply use
what is specified (default FRAMEBUFFER).
You bring up a valid use case, perhaps adding an "inherit render target" mode
for Cameras would be a nice feature for the osg core to have.
For the time being what I woul
Looking at the OSG code more closely there may be an easier way.
If you set the Camera's render order to NESTED_RENDER, it *will* inherit the
currently used render target.
Then set a RenderBin number on the camera to make sure it's drawn after the
scene. That should do it.
Cheers,
Jannik
Hi,
I just noticed a semi-random crash on exit in my application that seems to
point to a design issue in OSG.
In theory a crash can happen when you remove a previously used camera from the
scene graph, then modify something in the subgraph of that camera (e.g. remove
a node's child).
The rac
Hi Robert,
I know about the restriction with viewer-level cameras (add/removeSlave). I'm
not using those. I'm using in-scenegraph cameras for render to texture effects.
subgraph->addChild(rttCamera);
As far as I'm aware, in-scene graph cameras are not supposed to be subject to
threading issue
Hi,
>
> Your crash suggests otherwise :-)
>
Given that there is no documentation suggesting that removing RTT camera's is
unsafe - I just assumed it was a bug :)
As a workaround I believe that removing the Camera's children before removing
the camera should fix the crash. That means relea
Hi,
please correct me if I'm wrong (I have a naive understanding of VAO). I don't
see the point of VAO sharing. If a VAO can be "shared" between two Geometries,
that means the Geometries have the same set of vertex arrays, correct? So then
why use two separate Geometries to begin with if they a
Hi,
>
> The releaseGLObjects() and removeCamera() are there to make sure
> resources are correctly cleaned up. If you really try you can break
> it, like hiding resources from that active parts of the viewer/scene
> graph that are their to clean up things
>
Yes you can break it that way bu
Hi,
> You need to think about whether you need to delete Camera's
> dynamically during the applications life, you haven't explained why
> you are doing this and why not keeping the Camera around is not
> appropriate so I can't comment on the validity of what you are doing.
>
I don't need to
Hi,
I have tested out the VAO branch on my Nvidia graphics card. As you said,
VAO+VBO is slightly faster than VBO but not as fast as display lists. Would be
curious on the performance results with AMD cards.
Unfortunately, I am unable to use VAO for animated meshes because you've
introduced a
Hi,
>
> I have
> done this to avoid the extra checks required against the individual
> arrays to see if they are dirty or not - I have done it for
> performance reasons as I want to keep the CPU overhead for draw
> dispatch as low as possible.
>
Have you done benchmarking to see if avoidi
Hi Robert,
I can confirm that using dirtyGLObjects() does update the geometry.
I found a new bug, there seems to be a state leak somewhere in the interaction
of osgUtil::IncrementalCompileOperation, VAO and dynamic geometry. It's a weird
issue that comes and goes, some static meshes either flic
Hi,
The emitted particles following the node that they're attached to should be the
default behaviour of osgParticle, so there is problem something wrong in your
setup.
What you are describing is what would happen if the Emitter was a child of the
moving node, but the ParticleSystem itself is
Hi,
Check out my solution - no shaders needed:
http://forum.openscenegraph.org/viewtopic.php?t=15339
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69123#69123
___
osg-users mailing
Hi LiChi,
You are correct, this is a mistake that needs to be fixed, the following
for-loop is not even executed unless checkForGLErrors is true.
In fact, I've just spent an hour or so debugging a weird "Invalid operation"
GL-error and it turned out to be caused by exactly this bug - the StateS
Hi Nikita,
If you want to help finding the cause for the bug in master you can run a git
bisect.
git bisect will use a binary search pattern and give you commits to test on
your PC, usually this takes about 10 steps and you'll arrive at the problem
commit.
http://webchick.net/node/99
Once we
Hey guys,
Digging deeper into this issue, I found in the mail header:
X-Report-Abuse: You can also report abuse here:
https://sable.madmimi.com/abuse/new?id=64170.233867.1.89772119f10a5f14edc461729ba36bd9
So I went to that URL and filled out the abuse form, this is what I filled in:
"Unsolici
Hi,
I'm trying to use the frame number of the FrameStamp in osg::State for a double
buffering implementation in my custom drawImplementation() method.
However, the frameStamp in osg::State is just a pointer so when the frame
advances, it will be increased. The problem is that in DrawThreadPerCo
Hi,
@Riccardo: Haha, that's my own post ;) The FrameSwitch node is what I currently
do but I'm looking to clean this up a little. Since the double buffering is an
implementation detail ideally it would be handled by the node itself rather
than a decorator node that has to be part of scene graph
Found it:
https://github.com/openscenegraph/OpenSceneGraph/commit/7aae7206369528bcc3a2d6a5ed50e16b97f44a97
I was looking at the wrong branch (duh)
That should solve all my problems, thanks Robert!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70
Hi kornerr,
Try using Geometry::setUseVertexBufferObjects(true) - this should make OSG use
VBO's and EBO's (element buffer objects) instead of the standard display lists.
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70176#70176
Hi,
I was considering to use the buffer/texture object pool for my program (see
http://forum.openscenegraph.org/viewtopic.php?t=3844&view=previous )
What strikes me as odd, though, is how enabling texture buffer pools
automatically disables the use of unrefImageDataAfterApply() for textures:
On Nvidia, replaying the trace prints the following debug output for each
'glDrawElements' line:
Code:
usnknown (sic) severity API unknown issue 131185, Buffer detailed info: Buffer
object 1 (bound to GL_VERTEX_ARRAY_BUFFER_BINDING_ARB,
GL_TEXCOORD_ARRAY_BUFFER_BINDING_ARB (0), and GL_ARRAY_BU
Hi Johny,
By default, OSG will run graphics operations in a separate thread so trying to
do OpenGL calls from the main thread will not have an effect. Update callbacks
are always invoked from the main thread. Try using a DrawCallback on a Drawable
or Camera instead which will be invoked from th
Hi,
I've seen this quite often in the past; so far deleting the site cookies and
logging back in always solved it (for a while anyway).
Cheers,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70752#70752
___
Hi Nick,
I think what you're looking for would be Particle::kill():
Code:
/** Kill the particle on next update
NOTE: after calling this function, the isAlive() method will still
return true until the particle is updated again.
*/
inline void kill();
D
Hi James,
You should be able to use a Drawable with DataVariance set to DYNAMIC for the
'sync phase', and a second Drawable (with no special dataVariance) for the
drawing, with your logic implemented in the Drawable's drawImplementation().
RenderBins can be used to control when they are drawn.
Hi Miguel,
Overriding traverse() is possible, it's also possible to add a callback via
node->addCullCallback(myCallback) which is essentially the same just via a
callback object that can be reused for multiple nodes (of possibly different
types). I would usually go with callbacks as they are a
96 matches
Mail list logo