## SQBVH

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: jromang, tomb, zcott, coordinators

### Re: SQBVH

J the Ninja wrote:Found an odd bug with sqbvh, using it with this scene causes the instanced objects (the lamp housings) to just disappear!

I should have fixed this problem, it was triggered by the usage of no-triangle primitives (i.e. an area light with a sphere as primitive and instances): http://src.luxrender.net/lux/rev/3db8cbbf6887

Posts: 5550
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: SQBVH

J the Ninja wrote:Found an odd bug with sqbvh, using it with this scene causes the instanced objects (the lamp housings) to just disappear!

I should have fixed this problem, it was triggered by the usage of no-triangle primitives (i.e. an area light with a sphere as primitive and instances): http://src.luxrender.net/lux/rev/3db8cbbf6887

I verify commit fixes the issue ( JT's lamphousings are rendered now ).

Jens

jensverwiebe

Posts: 2284
Joined: Wed Apr 02, 2008 4:34 pm

### Re: SQBVH

jensverwiebe wrote:
J the Ninja wrote:Found an odd bug with sqbvh, using it with this scene causes the instanced objects (the lamp housings) to just disappear!

I should have fixed this problem, it was triggered by the usage of no-triangle primitives (i.e. an area light with a sphere as primitive and instances): http://src.luxrender.net/lux/rev/3db8cbbf6887

I verify commit fixes the issue ( JT's lamphousings are rendered now ).

Jens

Yep. All's fine now. Thanks Dade!

Btw, this also seems to fix the crash I had on the previous page. That scene has sphere lights and instances as well, so I'm guessing it was something to do with that.
-Jason

J the Ninja

Posts: 2425
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

### Re: SQBVH

J the Ninja wrote:Btw, this also seems to fix the crash I had on the previous page. That scene has sphere lights and instances as well, so I'm guessing it was something to do with that.

Yup, for sure.

Posts: 5550
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: SQBVH

There are still some cases where the sqbvh accelerator produces holes in the mesh.
The pictures show the result with different geometry and additional scattering media.

And sometimes I get this:

Code: Select all
[...]2012-03-16 16:35:53 Info: 12] A primitive of type class lux::InstancePrimitive, used in a SQBVH, isn't a triangle, falling back to bounding box clipping for building[2012-03-16 16:35:53 Error: 13] SQBVH unable to handle geometry, too many primitives with the same centroid[2012-03-16 16:35:53 Error: 13] SQBVH unable to handle geometry, too many primitives with the same centroid[...]

Resulting in this:
i7 860, 16 GB RAM, NVIDIA Geforce GTX 560 + GTX 460, Windows 7 64bit, Blender 2.68a
neo2068

Posts: 546
Joined: Sun May 03, 2009 2:11 am
Location: Germany

### Re: SQBVH

neo2068 wrote:There are still some cases where the sqbvh accelerator produces holes in the mesh.

The holes are more a side effect of the problem than the problem itself. QBVH can not store more than 64 triangles in a leaf. When the code is forced to produce a leaf and there are more than 64 triangles it has to discard all triangles after the first 64. This usually happen because it has reached the max. tree depth or because there are degenerated triangles.

At the moment, SQBVH seems to have some numerical stability problem and some time it starts to loop over the same split reaching the max. depth of the tree. There is a simple temporary workaround (i.e. http://src.luxrender.net/lux/file/12824 ... l.cpp#l481) to just stop spatial splits when thing starts to become too "small" but I'm looking for a solution of this problem. This is also one of the reasons why SQBVH performance can vary a lot on different scenes.

Neo2068, can you post the sources of the problematic scene ?

Posts: 5550
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: SQBVH

neo2068 wrote:There are still some cases where the sqbvh accelerator produces holes in the mesh.

The holes are more a side effect of the problem than the problem itself. QBVH can not store more than 64 triangles in a leaf. When the code is forced to produce a leaf and there are more than 64 triangles it has to discard all triangles after the first 64. This usually happen because it has reached the max. tree depth or because there are degenerated triangles.

At the moment, SQBVH seems to have some numerical stability problem and some time it starts to loop over the same split reaching the max. depth of the tree. There is a simple temporary workaround (i.e. http://src.luxrender.net/lux/file/12824 ... l.cpp#l481) to just stop spatial splits when thing starts to become too "small" but I'm looking for a solution of this problem. This is also one of the reasons why SQBVH performance can vary a lot on different scenes.

Neo2068, can you post the sources of the problematic scene ?

Here are the scene files. This is a ripped version of a more complex scene. Thus there are some unused and some strangely named materials. The walls are divided to fit a water surface which has been removed. There are some very long and thin triangles.
Attachments
cornell_media_sqbvh.7z
i7 860, 16 GB RAM, NVIDIA Geforce GTX 560 + GTX 460, Windows 7 64bit, Blender 2.68a
neo2068

Posts: 546
Joined: Sun May 03, 2009 2:11 am
Location: Germany

### Re: SQBVH

Dade wrote:The holes are more a side effect of the problem than the problem itself. QBVH can not store more than 64 triangles in a leaf. When the code is forced to produce a leaf and there are more than 64 triangles it has to discard all triangles after the first 64. This usually happen because it has reached the max. tree depth or because there are degenerated triangles.

That's something I always wondered: could we just do an arbitrary split of the triangles when something like this happens? Less efficient than having all triangles in the same set, but better than degrading the rendering.

Jeanphi
jeanphi

Posts: 7017
Joined: Mon Jan 14, 2008 7:21 am

### Re: SQBVH

jeanphi wrote:
Dade wrote:The holes are more a side effect of the problem than the problem itself. QBVH can not store more than 64 triangles in a leaf. When the code is forced to produce a leaf and there are more than 64 triangles it has to discard all triangles after the first 64. This usually happen because it has reached the max. tree depth or because there are degenerated triangles.

That's something I always wondered: could we just do an arbitrary split of the triangles when something like this happens? Less efficient than having all triangles in the same set, but better than degrading the rendering.

We could definitively do an arbitrary split but this condition should happen, for QBVH, only if all the triangles in the leaf are degenerated or with the same centroid (i.e. "unable to handle geometry, too many primitives with the same centroid"). So it will something useful only if you have more than 64 degenerated/equal triangles in a leaf (i.e. it should be quite a corner case).

Posts: 5550
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: SQBVH

neo2068 wrote:There are still some cases where the sqbvh accelerator produces holes in the mesh.

I should have fixed this problem with the latest patch.