Added clipping planes #103
Conversation
| @@ -335,6 +340,9 @@ enum class CameraMode | |||
| inspect | |||
| }; | |||
|
|
|||
| // A clip plane is defined by a normal and a distance to the center of the scene bounding box | |||
| typedef std::vector< Vector4f > ClipPlanes; | |||
There was a problem hiding this comment.
Is it difficult to define clipping planes like the usual plane equation?
That's what RTNeuron uses and I think that Livre also.
I don't like your definition because if I have some clip planes and then I change the scene that would change the clip plane position, that makes no sense to me.
There was a problem hiding this comment.
This definition packs the plane equation into 4 floats for implementation convenience. That makes it easier to transfer the data to the underlying rendering engine. What matters is what is exposed to the client: the definition in the fbs, and this is common to RTNeuron, Livre and Brayns.
There was a problem hiding this comment.
That's not my point. Both Livre and RTNeuron use 4 floats also. My concern is about the specification of what the 4th component means. In the usual plane equation the plane is defined by a b c d, and the points on the plane are those for which ax + by + cz + d = 0, in this equation a, b, c is a vector normal to the plane.
Your 4th component on the other hand is bizarre, because there's no way of writing a similar equation to the same before without knowing the bounding box of the scene, and that's something that changes, so your plane is not fully defined is it's not in the context of a specific scene, which is bad.
There was a problem hiding this comment.
The 4 floats contain absolute values, so changing the size of the scene does not affect the equation, and clip planes are reset anyway whenever the scene is changed. I'll update the documentation accordingly.
| @@ -308,7 +312,8 @@ enum class CameraType | |||
| perspective, | |||
| stereo, | |||
| orthographic, | |||
| panoramic | |||
| panoramic, | |||
| clipped | |||
There was a problem hiding this comment.
Why the clipping depends on the camera?
There was a problem hiding this comment.
It's the best solution with ray-tracing, both for simplicity and performance.
There was a problem hiding this comment.
That's an implementation detail to me. Can't you put the planes in the scene and then do the glue between the scene and the camera for the planes inside the OSPray implementation?
There was a problem hiding this comment.
Why should the clipping be attached to the scene? We are not selecting the data there, only visualizing a subset of it. The scene should definitely not be affected by the clipping planes. The camera definitely is the place where the clip planes should be handled.
favreau
force-pushed
the
master
branch
2 times, most recently
from
1f5edb0 to
b1a630f
Compare
favreau
changed the title
|
Ping! |
No description provided.