I have a need to visualization geometries made of 100,000’s of individual 2D
facet elements and I hoped to use the ROOT geometry package. I wrote a short
script that creates box elements to test how well ROOT works with a large
number of elements. I run into a problem when the number of nodes and volumes
exceeds approximately 8000. Specifically, using the attached script, the
following works:
root [0] .L TFacet.C
root [1] TFacet(20)
However, if I try:
root [0] .L TFacet.C
root [1] TFacet(22)
the following warning/error messages repeat many times:
Warning in : cache is full
Error in : no current capture open
I am running the latest CVS source on an Intel desktop running FC5.
I do not really know why GL cache gets exhausted - the GL developpers may answer better on this one. I have though some hint: in your example each volume is represented by a different object which the GL viewer tries to map and cache.
If you use a replication method, things may get better. As an example, I modified your macro which now instead of creating/positioning a new volume in each cycle, is just dividing a single box in X/Y/Z to reach an elementary cell. Now I position a single small blue box in this last cell. In this case in the geometry you have only 6 volumes instead of O(nFacets x nFacets x nFacets). On the other hand the effect is exactly the same - you get the O(nFacets^3) small boxes in the viewer…
I tried the attached macro up to nFacets=70, when my resources got to the limit…
but in TGLDisplayListCache’s constructor size parameter has default value
10000.
Andrei is right :
gl viewer was designed to use gl display-lists (for speed reasons). but if you have, say, 125000 (50x50x50)different objects and try to create 125000 display lists - it will not work, display list is a memory expensive feature, and 125000 display lists will eat huge amount of memory, so, this will break any optimisation (I guess, program even will not work at all). That’s why number of display lists created in TGLDisplayListCache is limited by 10000 - some reasonable number.
[quote=“gsalo”]Hi,
I have a need to visualization geometries made of 100,000’s of individual 2D
facet elements
Glen[/quote]
Hello Glen,
Let’s assume the ROOT works for you.
What did you expect to see? Can you elaborate the goal of your visualization?
The good modern computer screen is about 1000 x 1000 pixel = 1’000’000 pixels.
You want to get 100’000 boxes. Normally, 3 sides of each box should face the screen. This gives us the total number of the faces on the screen is about 300’000.
Assuminhg each face conatains 4 corners, we end up with 100’000 x 7 = 700’000 pixeles to be rendered. Roughly say to see what you want one may not go to the 3D graphics and the complex geometry scene. It is enough to paint all pixeles across of some screen area with one and the same color.
This means your case is quite exotic and one needs further information to understand whether 3D graphics is the real tool to help you.
Thanks to everyone who replied. I think I found a solution to my problem. In my case, I do need to draw more than 100,000+ distinct facets. The large number of facets is the result of discretizing the surface of a large structure, e.g., a ship. Typically, an IGES model of the ship is discretized into surface triangles or facets. In many cases, the number of facets turns out to be quite large. And reducing the number of facets is not always possible since my analysis requires high geometric fidelity.
Anyway, the solution I found employs the class TGeoCompositeShape. With this class, I can group many geometry elements into one volume and avoid the problem of having too many volumes. The attached script illustrates my approach.
My question now is whether this is a good approach and if there is another way I can achieve my goal.
Glen, you still do create much too many objects - now these are TGeoBBoxes. Try to define the minimal set of boxes having the dimensions you need and then re-use these when creating composite shapes/volumes.
I don’t know if this is the best approach - TGeo is not a surface-oriented model, but try to limit the number of components for composite shapes to maximum 20…
Glen, you still have to deal with 700’000 pixels on the screen whatever method you choose to describe your scene. To assist you one needs to understand your final goal. Why do you think the 3D picture of the 100’000 boxes on the regular computer monitor might help you to resolve some task ?
I mean whether you do really want ALL of them to be rendered at once?
Thanks again for your help. In my particular problem, I am calculating the probability of where lightning will strike complex structures such as ships, planes, buildings, and so on. In order to correctly predict the lightning strikes, I need to model small features like a lightning rod as well as large features such as a ship’s hull. Because creating such models is very time-consuming, using an existing CAD model is preferred. Generally speaking, the manufacturer exports the CAD model they developed in Pro/E, CATIA, UniGraphics, AutoCAD, …, to an IGES (Initial Graphics Exchange Specification - Valeri you were correct) or STL (stereolithography) model. At present, my code only works with STL models, so I have to convert the IGES files to STL files.
The STL description is a facet-type of description, i.e., a list of triangles that describe the surface. In general, no two triangles have to be identical. This leads to the situation where a model can contain over 100,000+ uniquely sized triangles. My goal is to find a way to use the ROOT geometry to visually display the geometry without modification. Although there are other visualization tools that display STL files with such large numbers of facets, using ROOT is attractive, particularly if I could overlay histograms or statistical strike results onto the 3D geometry. Perhaps ROOT is not the best solution, particularly since it seems like one is forced to created large numbers of either geometry elements or volumes. Short of developing surface elements for the ROOT geometry classes, do you see a way of using ROOT that makes sense?
In fact what you want is a direct access to the GLviewer facilities to just
store a long list of triangles. That is what the geometry rendering engine is doing.
I will ask Matevz Tadel (our GL expert) to propose a solution
to your problem.
If I understand correctly you want to render a set of triangles, each specified by a normal and 3 vertices. Probably you do not need the TGeo package at all.
In ROOT’s GL viewer there is the possibility to directly pass your data-object to the GL viewer and provide a direct GL rendering class. It should not be too hard to provide such functionality for your needs.
Do you want to assign per-vertex or per-triangle colors as well? These could be used to represent your probabilities … maybe …
Do you know in advance the number of vertices/triangles? If yes … this would simplify the implementation.
Were you considering compressing the vertices? As each vertex is shared by several triangles this can lead to significant reductions in memory consumption.
Let me know what you think … I could implement a first version of this in the beginning of next week.
[quote=“gsalo”] . . .
The STL description is a facet-type of description, i.e., a list of triangles that describe the surface…
. . .
I could overlay histograms or statistical strike results onto the 3D geometry.
. . . .
Short of developing surface elements for the ROOT geometry classes, do you see a way of using ROOT that makes sense?
Glen[/quote]Hello Glen , Look up again the star.bnl.gov/STAR/comp/vis/StarCollision.wmv ) To visualize your data you need to write about 10-20 lines of the C++ code (with Coin3d), the rest of the job can be done with ROOT, and all of above within one and the same application.
All what you say is wrong, plain wrong. You are just confusing a user
by asking him to import a complete system with plenty of dependencies
and problems and at the end less performant than a simple solution based on ROOT native graphics with the GL viewer as proposed by Matevz.
[quote=“brun”]Valeri,
All what you say is wrong, plain wrong. You are just confusing a user
by asking him to import a complete system with plenty of dependencies
and problems and at the end less performant than a simple solution based on ROOT native graphics with the GL viewer as proposed by Matevz.
Rene[/quote]Hello Rene. I did not ask user to “import” anything. Frankly, I have no idea what do you mean speaking “import” as soon as software is concern. I just share the real life experience and suggest to evaluate it.
Why dou think sharing my own experinece and real working appication is wrong? What is wrong with the concrete example I mentioned? What else can I share then? It was published see indico.cern.ch/conferenceDisplay … Id=a055638 . That time you did not say it is “wrong”. Please elaborate. We do value your opinion and will fix it ASAP. Please, help us to improve that package.
What dependency you are speaking about? Is it OpenGL?
[quote=“brun”]"at the end less performant [/quote]. To render things Coin uses the OpenGL. So it is as fast as OpenGL. ROOT does use OpenGL too. Why do you think it should be “less performant” for this particular task. All this guy wants can be described with one Coin object (for example: doc.coin3d.org/Coin/classSoTriangleStripSet.html ) that should be translated to one sigle OpenGL list. Where did you see the possible bottleneck?
What about ROOT. I agree one has to add a few extra TGeoShapes (TShape too ) ( let’s call it TGeoPrimitiveShape, to be concrete) to be a collection of the all possible OpenGL primitivies: rush3d.com/reference/opengl- … fig2-6.gif . I agree it should be simple with all ROOT signature features (like browsable, writable etc) in place. That should not have required any change on the Viewer3D level, by the way.
Many thanks for your offer. In general, yes, the number of triangles is known. In fact, the triangles that make up the entire structure are usually grouped by component, i.e. doors, windows, walls, and so on. In each case the number of triangles that form each component as well as the number of triangles for the entire structure will be known.
It would be particularly nice if the triangles that describe each component can be grouped into their own node. In some cases, the components need to be translated and rotated into the correct position and grouping each component into a separate node would be very beneficial.
Coloring nodes and individual triangles would be great. Likewise, your suggestion for compression is a good idea.
I also like Valeri’s suggestion to add other OpenGL shapes, particularly points and quads.
Please let me know if I can provide you with additional information or sample files.
I’ve prepared the first version of the TTriangleSet.
So far all the code is in a single file (TTriangleSet.C containing two classes: TTriangleSet and TTriangleSetGL; eventually this should be split apart). See the attached tarball.
I generated an intentionally lousy tessellation of a torus for a test (the file just lists number of vertices, triangles and then dumps the vertices and triangle-vertex indices).
to run:
tar xzf tset.tgz
cd tset
root triangleset.C
You can then run (from the root prompt):
g_ts->GenerateRandomColors()
click updateScene in the gl viewer to refresh the view
or call ‘gPad->Modified(); gPad->Update();’
I didn’t do anything on the vertex compression yet (but have been thinking about it). Let me know if you need it.
It is very easy to add a transformation matrix. I’ll do it tomorrow …
I’ll keep in touch.
Cheers,
Matevz
[10.10.06 10.30: I added the tarball … yesterday it was rejected because of .tgz extension.] tset.tar.gz (8.19 KB)
) ( let’s call it TGeoPrimitiveShape, to be concrete) to be a collection of the all possible OpenGL primitivies: 