Open ggalgoczi opened 2 months ago
In Opticks publication it is stated that primitives can be used for ray-tracing: https://doi.org/10.1051/epjconf/202429511014
The stree intermediate model carries solid shape information within an n-ary tree of sn.h CSG nodes. The Opticks CSG package implements ray primitive shape intersection in simple headers that are CUDA compatible but can also be used and debugged on the CPU. These functions use implicit equations for the primitives together with the parametric ray equation, to yield a polynomial in t, the distance along the ray from its origin position.
Next step is to find where this happens.
The ray-tracing intersection and bounding box functions are defined for the following primitives:
https://bitbucket.org/simoncblyth/opticks/src/master/optixrap/cu/csg_intersect_primitive.h
Next step is to understand whether GDML files can be easily translated into CSGTrees.
In #20 I added the previously missing G4 user actions. Now, when I run simg4ox
I see the output folder filled with CPU and GPU results. I am going to verify the output next but I think this minimal standalone utility can be already used for further experiments like this one.
Thanks @plexoos! The next step would be to implement the same thing with Opticks both GPU and CPU and compare them with the G4 output, right?
Within the context of GPU geometry definition (CSG binary tree) even Union is implemented. There are three: CSG_CONTIGUOUS Union -> like G4MultiUnion CSG_DISCONTIGUOUS -> no overlaps, eg. "union of holes" to be CSG subtracted CSG_OVERLAP -> full overlap, eg. G4Sphere
For Subtraction CSG_DIFFERENCE is the keyword
I've reviewed optixrap
from Opticks, and here are my observations:
optixrap
is not compatible with OptiX 7.The steps of geometry transformation are the following:
G4 —--———————> sysrap/stree.h —————-----——> CSG/CSGFoundry ———-----——> OptiX AS
I printed out CSG node and primitive information of opticks_raindrop.gdml. The following two functions:
CSGFoundry::descPrim()
CSGFoundry::descNode()
returns 911 primitives and 1325 nodes. Primitives define the volume information while node define the hierarchy of said primitives. Primitive information is still preserved here.
Eg. a cylinder and a box:
CSGNode 2 cy aabb: -650.0 -650.0 -1740.0 650.0 650.0 -1240.0 trIdx: 2 subNum: -1 subOffset:: -1 CSGNode 11 bo aabb: 430.0 -305.0 -1739.8 550.0 -185.0 -1707.8 trIdx: 7 subNum: -1 subOffset:: -1
Ultimately in SBT::createGAS() there are two options to upload the GAS to GPU. One is analytic geometry and other is trimesh. I will try to run that when the GPUs will be free. Let's see if it is used..
Analytic geometry is uploaded to the GPU since the following function is called:
// analytic geometry
SCSGPrimSpec ps = foundry->getPrimSpec(gas_idx);
bi = new SOPTIX_BuildInput_CPA(ps) ;
gas = SOPTIX_Accel::Create(Ctx::context, bi );
Which example/test did you use to see this?
I modified opticks/g4cx/G4CXOpticks.cc and opticks/CSGOptiX/SBT.cc to print out what is happening and just called
./build/src/simg4ox -g esi-g4ox/geom/pfrich_opticks.gdml -m esi-g4ox/run.mac
@plexoos you were right that optixrap is not used anymore.
However I likely found where the new primitive intersections are defined for Optix7. An example:
CSGOptiX7.cu uses csg_intersect_leaf.h that includes primitive intersection files like csg_intersect_leaf_sphere.h.
I did not yet find how it is linked to G4CXOpticks yet.
Oh, nice! I’d expect these header files to be included in some .cu files compiled by nvcc.
Understand if triangulation is a must for geometry definition on GPU and if the current framework uses it.