Hi,
In ROOT, I define some boxes and plot them in 3D view. The wire color of each box is a weight given. In the mean time, I have another program to do the same thing. Their comparison plot can be found in the attachment. The difference between is for the ROOT plot, internal lines in TShape are visible so that the whole picture looks very mass (see left figure). For the plot made by another program, the internal lines are hidden somehow (see right figure). The whole picture looks very clear. I am curious if in ROOT I can hide internal lines?
You may ask why you cannot use the 2nd program instead of ROOT? The reason is I want to do the same thing in ROOT so that I can run my jobs (like save images) in batch instead of doing manually.
As you noticed, in wireframe mode we do not do hidden line removal. Are you using OpenGL to view this?
What exactly are you trying to do? What is your input data? I’m asking, because there are other options, better than TShape classes.
If your data is a TH3, there are several display methods that can show your data in various ways. As a start, see tutorials/gl/glbox.C and some other things in this directory … Timur can help you with this.
If you have “raw” box data, maybe TEveBoxSet could do it for you, see tutorials/eve/boxset.C. Here I can help you and, if needed, add another option/mode for drawing of boxes.
I guess you mean the right figure? I use a tool called MeshTools3D:
[ul]For viewing 3D models that are represented by a rectangular mesh in the UBC-GIF format, with optional topography. Functions include mesh construction, display via slices (in either dimension or diagonally) and isosurfaces (positive or negative), overlay of surface data as a transparent colour contour map, rotation, animation of views, block model construction, and (if forward codes are licensed) calling of forward 3D magnetics or 3D gravity codes. [/ul]
I try to view a density map, basically, x, y, z and weight in color.
Yes, I am using this approach although I really want to plot ‘raw’ box data.
Good to know this. I am playing with it. I have two questions:
I have total 0.5 M boxes to plot and it turns out it is very slow. I read some references about REVE, this number is supposed to be small and should be quick to plot. MethTools3D runs this set of data very quick, no delays.
I am curious if any advanced visualization algorithm available to plot only surface to accelerate. For example, given a view, only the ‘visible’ surface facing a reader is shown, thus may do things much faster.
Timur was working on some advanced density visualization stuff … can you put your data set somewhere on the web (as a ROOT TTree, if possible) and I’ll ask Timurto have a look.
Now, I tried running boxset.C with 0.5M boxes on my laptop … it takes about half second to draw. What we could do to speed it up:
If you are zooming in on the dataset, it would help to split it up into several boxsets, each covering a 3D cube. We only draw things that are in view, so this could reduce number of things that we need to draw.
I can draw only half, or one third (or 1/n) of boxes while rotation with a mouse is in progress. This should make it more interactive.
I can add support for more advanced OpenGL features … the reason why we avoided this in the past is that most of HEP community uses SLC5 (RHEL5 derivative) and we have to support rendering with OpenGL-1.4. Since then we added run-time GL capability detection support so I could have a look at that and see what can be done to speed it up.
What box-set type are you using? If all your boxes are of the same size it would already help if you use kBT_AABoxFixedDim instead of kBT_AABox which is used in the tutorial.
kBT_AABox axis-aligned box: specify (x,y,z) and (w, h, d)
kBT_AABoxFixedDim axis-aligned box w/ fixed dimensions: specify (x,y,z)
also set fDefWidth, fDefHeight and fDefDepth
Out of curiosity, what graphics card / drivers do you use?
I tried my file. It takes several second to draw, but the real problem is that I cannot really interact with the drawing, very slow.
This is a smart approach.
I consulted with the author of MeshTools3D mentioned above, he said he only used the OpenGL lib. So I believe more advanced OpenGL features can improve performance.
Good to know this. I just tried this. It looks like no too much improvement.
I tried your example with your data … the redraw time is about 0.5 sec on my computer … I guess they are buying me too good hardware these days It is also fun to narrow the signal range and use the slider to see the “slices”.
I’ll try to get some time to implement the “thinning” during rotation as soon as possible … I’m quite late with another project and I got other people working with me now so it’s hard to switch. What is your time-scale for this? Are you comfortable working with the trunk of root?
I implemented the change, you need to call something like:
from your macro.
Now, the main problem with rotation seems to be the starting / reaction time when rotation should start. I observe a couple of seconds wait time – the reason for this is that you call:
This makes a detailed, two-level selection pass on on almost every mouse move (to support highlighting of individual boxes). Do you actually need / use this feature? Try commenting this out to see if there is some speed-up.
It is also fun to narrow the signal range and use the slider to see the “slices”.