Debugging the OSG code it seems most of time spent before seeing the picked
triangle with adifferent color is inside "ViewerBase::renderingTraversals()",
and exactly in the following line:
if (_endDynamicDrawBlock.valid())
{
_endDynamicDrawBlock->block(); // <-- HERE!
}
Any
Just an update.
OSG KdTree works great!
Computational time for "camera->accept(intersectionVisitor)":
before it was about 10M microseconds
with KdTree it is about 25 microseconds!
This is the code I modified in my example:
Code:
osg::Node* createScene() {
osg::Geode* geode = new osg::Ge
Thanks Jordi for the fast reply.
I will try with Kdtrees. In fact USE_FLOAT_CALCULATIONS does not help much.
I have one more issue.
As you can see in my previously attached example, after mouse picking, I
basically set:
geometry->dirtyDisplayList();
geometry->getColorArray()->dirty();
Those met
HI Gianni,
For faster intersections it is far better to build the kdtree first. Also
splitting your huge geometry in several could help to traverse the graph in
case you don't want to use kdtrees.
Cheers.
2017-07-18 12:17 GMT+02:00 Gianni Ambrosio :
> Hi All,
> I built a test geometry with abou
Hi All,
I built a test geometry with about 9M triangles and 27M vertices. The intent of
my spike solution (attached) is to select a triangle with mouse to change its
color. I realized that the bottleneck of that code is the line where the camera
accepts the "osgUtil::IntersectionVisitor" (line 5
Hi Sebastian,
sorry I missed your reply.
SMesserschmidt wrote:
>
> Most probably your problem is lighting. Your surface is shaded correctly
> while your wireframe stays constant. At a certain angle the lit result is
> simply the same color as your constant wireframe.
>
I think you are right.
6 matches
Mail list logo