Depth mapped volume style #540
Conversation
RenderedTexture node.
test/regression-suite
| " vec3 cam_pos = vec3(modelViewMatrixInverse[3][0], modelViewMatrixInverse[3][1], modelViewMatrixInverse[3][2]);\n"+ | ||
| " cam_pos = cam_pos/dimensions+0.5;\n"+ | ||
|
|
||
| " const float steps = 200.0;\n"+ // take care! ANGLE does loop unrolling, setting this too high might not give any compile error but could give weird results |
There was a problem hiding this comment.
Could this be "60.0" steps, in order to be consistent with the other volume rendering nodes?
…Utils.initFBO. Modified DepthMappedVolumeStyle to use alpha value of transfer function for composting.
|
@aarbelaiz Hi, thank you for your comments and pointing out the typo. |
|
Thanks for this great contribution! Having arbitrary clipping planes sounds like a really nice candy, on top of the already great feature of combining volumetric and polygonal data! @aarbelaiz Please tell me when this is ready for merge - and thanks a lot for taking the time to check this stuff! Also, thanks for providing a test case. As soon as this is working inside the dev branch, it would be really cool to also have an example, which we could put on examples.x3dom.org. |
|
@aarbelaiz Thanks for the helpful comments and suggestions - please let me know if you think this is ready for merge. |
|
@aarbelaiz any update? can we merge this one? |
|
Sorry @mlimper for the delay, in the mailing list http://sourceforge.net/p/x3dom/mailman/message/34428520/ I gave my opinion explaining where this contribution should be headed to. I though @ankit1089 and his co-workers agreed to them, if this is correct I would propose to change the name of the node to RadarVolumeStyle and explicitly state in the documentation that this node is a X3DOM node, and not a X3D node. In the future, I would like to see the functionalities of this node available in the regular X3D nodes so that a non-standard additional node is required. In the meantime, the proposed node could be merged knowing it could be subject to change in future versions of x3dom. |
|
Cool, thanks for the feedback. I really like the feature of combining volume renderings and rendering of polygons, this is a very nice feature, and I belive X3DOM users will really like it. |
ankit1089
force-pushed
the
depth_mapped_volume_style
branch
from
0da6710
to
6546395
Compare
|
@mlimper @aarbelaiz Sorry for delaying this merge. As discussed with Ander Arbelaiz in the mailing list, we are trying to implement the combined rendering of polygons and volume data in the "X3DVolumeDataNode" so that other volume styles can also use this functionality. Also, we are trying to implement clip planes for the volume data using the already existing ClipPlane node. We are working on the new code at : https://github.com/ankit1089/x3dom/tree/depthTexture_volumeData but it is still buggy and in development. Right now both of these functionalities are implemented in the shader of the DepthMappedVolumeStyle (renamed to RadarVolumeStyle) of this pull request. I renamed the node to "RadarVolumeStyle" for this pull request to get merged. Later on, we would like to replace it with a better implementation. |
This is a really exciting feature, and I believe a lot of X3DOM users will be very happy to have it. It will also be an interesting key feature of X3DOM. Please keep us updated, as soon as your code becomes stable enough for merge. I'll now merge this one then. Do you have an example which I could put on examples.x3dom.org to showcase this first version of combined rendering (volumes + polygons)? |
|
@mlimper Thanks for the merge! I will make a demo for this email it you. |
|
perfect, looking forward. |
|
I am using RadarVolumeStyle to great effect, all works as expected (except or #537). So this is more a request for enhancement or instruction what would could be done to the shader to avoid these kind of artefacts along oblique cross-sections:
These are most obvious for intensity=1 but also show up for smaller intensities. Is there a place in the code to somehow supersample the texture ? Here is the full scene: |
|
Those artifacts are to be expected, you can increase the number of Steps of the ray casting to achieve a better result with more sampling. |
|
Ok, changing to Step =120.0; in X3DVolumeData.js works great. I created a simple Greasemonkey user script here: https://gist.github.com/andreasplesch/4b2742e6260cde371c31 Install by clicking on Raw. This way an unaltered x3dom-full.js can be used. I think it would be really useful if the Steps parameter could be exposed as a SFFloat field to X3DVolumeData, perhaps called "steps" or "rays" or "quality" . The default could be 60.0. Some sanity checking may be necessary but the assumption should be that a user knows what he is doing if she is changing the default value. Perhaps a log warning if larger than 240 and smaller than 15 ?
|
|
The "steps" | "quality"... field is not in the X3D specification, it is more related to the implementation, thus there is no such argument in the X3DVolume nodes... If added it would be a X3DOM argument only. Do you still see it necessary? |
|
Yes, I still think such a field would be very useful. Authors who want a spec. compliant scene do not need to use it. Authors who want to take advantage will know that it is x3dom only. There are many other x3dom only fields and nodes which work by the same principle. |
The DepthMappedVolumeStyle generates a volume rendering based on ray casting.
The rays terminate when they encounter a polygonal object inside the volume. Depth upto
which a particular ray can travel inside the volume is calculated from the depth buffer
of the polygonal objects in the volume.
The node also provides a method for generating flat cross-sectional views of the volume
at arbitrary orientations.