Re: Ideas request for a specific raytracing application

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> I build an orthonormal basis with the normal being an axis - the cosine_sample_hemisphere() function (which just happens to be already there) assumes that the hemisphere is above the x/z plane. PBRT guys do it similarly (I believe), but doing it in object space would also be ok.
But this I also wrote in the program's comments, so it's probably not what you're worrying about. So AO means you sample the hemisphere above the intersection position. In order to find the hemisphere, you need the normal. Then you (may) form an orthonormal basis with the normal being the up direction. Then you sample the hemisphere. Rays that hit an occluder "darken" the resulting color.
Probably no news to you, just wasn't sure if I got your question right.
Best regards,
Stefan

(L) [2015/06/25] [tby mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> szellmann wrote:But this I also wrote in the program's comments, so it's probably not what you're worrying about. So AO means you sample the hemisphere above the intersection position. In order to find the hemisphere, you need the normal. Then you (may) form an orthonormal basis with the normal being the up direction. Then you sample the hemisphere. Rays that hit an occluder "darken" the resulting color.
Probably no news to you, just wasn't sure if I got your question right.
Best regards,
Stefan
Yes that sounds all right for me, I was just confused looking in the code and the naming of w,u,v and the use of SIMD to calc the new direction (I am not familiar with hemispheres implementation).
I guess this could be used similar if you want to compute soft shadows from lights.. but in this case I should use the direction from point to light. (and adding a bit of jitter may help..)

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> I am still working on that, but so far, the PCB can be represented by circles, round segments (== two circles + rectangle), and polygons for areas.
I can provide more detail later, but in face I have this 2D simple objects that I use to combine and construct the more complex CSG combinations. (All CSG operations are in the form (object A - object B) intersection object C, .. they can be really objects or can be 1 or 0, so, no intersection or always intersect ).. and so on.
Ok, so you probably have geometry that is curved in a way but has no closed form solution when intersecting it with a line (such as the curved creases of the main boards).
When going for real-time ray tracing you should minimize the number of supported primitive types (e.g. only triangles, or only quadrics). This is because you'll have some switch case (or similar) in your inner traversal loop, that must determine each time what primitive type you'd like to intersect. In the best case, you'd like to do away with the switch case completely (by only having a single primitive type).
In Visionaray we have a "generic_primitive". This is basically just:
Code: [LINK # Select all]variant<prim_type1, prim_type2, ...>
When saying e.g. Code: [LINK # Select all]typedef generic_primitive<triangle, sphere> primitive_type;
instead of simply
Code: [LINK # Select all]typedef triangle primitive_type
, performance drops significantly (I believe by 25% or so), even if the model we actually render consists only of triangles. This is only due to the switch case (that is hidden inside the variant).

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> I guess this could be used similar if you want to compute soft shadows from lights.. but in this case I should use the direction from point to light. (and adding a bit of jitter may help..)
I believe you can think of AO as sampling an environmental light with uniform intensity (and no direct light sampling, for that matter).
Doing a lot of posting lately, don't want to scare off other potential posters [SMILEY :D]
Best, Stefan

(L) [2015/06/25] [tby mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> szellmann wrote:When going for real-time ray tracing you should minimize the number of supported primitive types (e.g. only triangles, or only quadrics). This is because you'll have some switch case (or similar) in your inner traversal loop, that must determine each time what primitive type you'd like to intersect. In the best case, you'd like to do away with the switch case completely (by only having a single primitive type).
, performance drops significantly (I believe by 25% or so), even if the model we actually render consists only of triangles. This is only due to the switch case (that is hidden inside the variant).
Yeah, I know it from the literature. Yes, I know that I am using this different primitives derived from a generic (C++) object with pure virtual functions and that don't help the performance [SMILEY ;)]
I cannot consider just triangles, because that will be back to the same issues before that I have to construct and compute the tessellation / triangle final scene.
Mind also that I should consider here the pre-compute time + rendering as a whole, so it is best to have a pre-compute time fast and get some image, the "final" render can take about (lets say.. ) 1 second or more. and the interactive low quality can be ~3 .. 5.. 10fps should be fine.

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> Yeah, I know it from the literature. Yes, I know that I am using this different primitives derived from a generic (C++) object with pure virtual functions and that don't help the performance
I cannot consider just triangles, because that will be back to the same issues before that I have to construct and compute the tessellation / triangle final scene.
I would not suggest using virtual C++ objects. Problem is that you store pointers. What you want to do is store primitives contiguously in memory. With virtual objects, you just store pointers contiguously in memory, while the primitives are probably scattered. Bad for caches. A way to achieve the former would be to use unions:
Code: [LINK # Select all]union primitive
{
sphere s;
triangle t;
};

and a function Code: [LINK # Select all]intersect(primitive) that dispatches (e.g. via a switch statement) to specialized functions. A more versatile union is called a variant. We found the boost implementation to slow for our needs, so we implemented one of our own. I cannot provide any numbers (using virtual inheritance vs. using unions), but intuition (and a particularly nice C++11 paper by Bjarne Stroustrup i can't find at the moment) tell me that you want to align your objects in memory.

(L) [2015/06/25] [tby mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> szellmann wrote:I would not suggest using virtual C++ objects. Problem is that you store pointers. What you want to do is store primitives contiguously in memory. With virtual objects, you just store pointers contiguously in memory, while the primitives are probably scattered. Bad for caches. A way to achieve the former would be to use unions:
Code: [LINK # Select all]union primitive
{
sphere s;
triangle t;
};

and a function Code: [LINK # Select all]intersect(primitive) that dispatches (e.g. via a switch statement) to specialized functions. A more versatile union is called a variant. We found the boost implementation to slow for our needs, so we implemented one of our own. I cannot provide any numbers (using virtual inheritance vs. using unions), but intuition (and a particularly nice C++11 paper by Bjarne Stroustrup i can't find at the moment) tell me that you want to align your objects in memory.

I see thanks. I did something like that when I coded a plain C raytracing.
My plan is to first "make it work" getting use of this OOP capabilities so I can archive results faster.
I read also a bit about cache friendly algorithms and I understand your propose. But.. I plan to keep the things (class and structures) aligned with sizes multiple of cache lines, so if I consider that some "random position in RAM" need to be fetched .. it will stay sometime in the cache (.. lets say.. L2..)
Another idea is to try some "packet ray" (with no SIMD .. first) .. so lets say even if I got something from memory it will come in multiples of cache lines and should stay a bit in the cache.. so. I don't know how much I could gain / loose if I follow the OOP approach VS the array of primitives.
I am thinking, in triangles only RT the ideal situation would be to have all triangles in a big aligned array.. and process it in batch using SIMD packs.. but.. I think there is still no way that will make sure that you hit one triangle and the next one is placed right next to you in object space.. and . in memory space.
Well.. things to be investigated latter!..

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> I think there is still no way that will make sure that you hit one triangle and the next one is placed right next to you in object space.. and . in memory space.
The primitives in your BVH node can and should be stored contiguously.
If you use polymorphism, you have to store (say) an std::vector<renderable*> rather than an std::vector<renderable> because the latter slices. And a renderable* you have to create with new(). You have no real control where (default) new() actually places the prims, even if your primitive struct has padding bytes and alignment attributes and so. During BVH construction you probably also sort them, so the prims stay somewhere in free store, and only the pointers are in order.
I don't want to drift off further by answering questions you didn't ask [SMILEY ;)] it's just that I wanted to point out (and here it relates to your original question) that the choice of primitives may also impact (rendering) performance. But then, if your use case demands only a few hundred primitives, it maybe doesn't matter at all. If you can do w/o the tessellation, it will probably in any way be a huge gain.
If you opt for using ray tracing, you should consider using a library for the low-level stuff [SMILEY ;)]
Cheers,
Stefan

(L) [2015/06/25] [tby mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> szellmann wrote: The primitives in your BVH node can and should be stored contiguously.
I see, I was thinking that when you load a model from a file, you cannot assure that one polygon is next to the other. So I guess you mean that in BVH, you try to keep the polygons next to each other (as they are in object space)?

>> szellmann wrote: If you opt for using ray tracing, you should consider using a library for the low-level stuff
What do you mean / suggest?
I am developing almost everything from scratch. The libraries that I am (free to) using are:
OpenGL Mathematics (GLM) (for vectors, matrices, also it support SIMD, ...), Boost .. not much but I can use it if I need, OpenGL, Clipper (for polygon operations)..
Since this will integrated an already existent opensource project, there are some restrictions to add new (external or integrated) libraries (licences, team approve, etc)
Most of the parts I worked so far, are very specific to this project (primitive types and PCB model construction..etc)
I am reusing some source pieces from some other authors / projects that I am giving credits of course.
Mario

(L) [2015/06/25] [tby szellmann] [Re: Ideas request for a specific raytracing application] Wayback!

>> I see, I was thinking that when you load a model from a file, you cannot assure that one polygon is next to the other. So I guess you mean that in BVH, you try to keep the polygons next to each other (as they are in object space)?
Yeah, BVHs are hierarchies of bounding boxes of spatially nearby triangles. Often you only store four tri's in a node, but if they are far apart in memory, that hurts performance.
>> What do you mean / suggest?
I would take the BVH code from somewhere else. It's tricky to get it right (and fast).
As a library developer, of course I recommend using my own library, Visionaray [SMILEY ;)]
Embree is the state of the art, but no GPU code unfortunately. Very cool for incoherent rays because of a special BVH type.
Aila and Laine's BVH kernels from 2009 are the GPGPU state of the art I think.
I like appleseed very much, their code is really, really clean. I'm not sure if it can actually be used as a library.
I also always think twice before depending on an additional external library - I believe all the ones I mentioned have a license where you can simply copy code (e.g. MIT license).
>> OpenGL Mathematics (GLM) (for vectors, matrices, also it support SIMD, ...)
GLM is a good choice [SMILEY :)]

(L) [2015/06/25] [mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> szellmann wrote:I would take the BVH code from somewhere else. It's tricky to get it right (and fast).
As a library developer, of course I recommend using my own library, Visionaray
Embree is the state of the art, but no GPU code unfortunately. Very cool for incoherent rays because of a special BVH type.
Aila and Laine's BVH kernels from 2009 are the GPGPU state of the art I think.

Another issue / condition (however I didn't discuss this with anyone in the project) is that would be nice if it can keep the compatibility with old machines.
So I must consider the case "no SSE", "no GPU shaders". I heard that there are still people using very old machines with this tool..
I have in mind to try some ideas on "sparse grids" ? (multi-level grid) and then I will keep the things flexible to try BVH.
What is appleseed? And how can it help me?
Mario

(L) [2015/06/28] [koiava] [Re: Ideas request for a specific raytracing application] Wayback!

As this is very specific case, when you have PCB board, you can increase efficiency of different parts of your renderer. Most of performance goes on determining Visibility, To increase performance of evaluating visibility you definitely need good acceleration structure.
1. Geometry will be static in most cases, so I think and best choice of acceleration structure will be SBVH because primitives in PCB may have different sizes and alignments.
With SBVH you need to implement spatial splitting for your primitives, As you have different types of primitives it may be more difficult to implement or you can use fullSAH BVH with early split clipping instead of SBVH.
2. PCB components are mostly not rounded and are Axis aligned, this will greatly improve efficiency of bounding boxes.
3. As you mentioned it above, PCB is plane with components on it. In this case packet tracing for primary rays will give you huge speedup. you can use packets for shadow rays to if you will have small area lights.
4. I think mostly used illumination type will be Environment illumination. Global Illuminations means that you calculate all the light paths with all the different lengths. In case of PCB, when board is viewed under some Environment illumination(outdoor scene) I think most of paths will have lower length. In most cases there will be less then 5% above 4 hits. So it will converge fast.
5. Most relevant for real-time rendering is unidirectional path tracing, but as PCB has different metallic parts on it it will create some caustic paths. So you can use more robust integrator to get clear, converged final images.
If you will render only board then generating light paths will be efficient. You can use VCM as it's publicly available, but it has much more startup time and as you need real-time rendering you need to deliver first images fast. You can generate first image from light path to show something and then replace it with final delivery.

(L) [2015/07/01] [mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

Hi koiava,
thanks for your valuable suggestions!
would you please elaborate more the 4 and 5? regarding "Environment illumination"? Any papers?
Right now, I dont plan to go for something so advance as the path tracing Another aspect is that in my scenario application I dont have easy way to setup the materials (or in other words: the file models of the components usually dont have material information) so there is not much to gain using advanced illumination models.
Mario
>> koiava wrote:...

(L) [2015/07/02] [koiava] [Re: Ideas request for a specific raytracing application] Wayback!

Environment Illumination is really great for such type of CAE applications.
As the final shading result is dependent on 2 factors, brdf and light, variance coming from both parts will effect on final result.
Brdf sampling is really easy, you generate some reflected directions proportional to your BRDF(distribution might be not exact but near to BRDF, in such case you need to weight them proparly).
So, when you generate samples proportional to BRDF you are importance sampling material but as I said final shading result is dependent on both: brdf and light, so you may sample some area of environment and another area may have big effect on final result(bright sun light on environment for example). You definitely need both sampling strategies, brdf sampling and light sampling. As the variance comes from low probability of sampling important paths you can calculate sampling probabilities for both strategies and combine results with [LINK https://graphics.stanford.edu/courses/cs348b-03/papers/veach-chapter9.pdf MIS]. there is also great technique called [LINK http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.70.139&rep=rep1&type=pdf RIS], you can use it as addition.
>> Note: any light sampling technique is some sort of importance sampling, importance sampling might be both good and bad. It may increase variance, when prediction is not valid. Importance Sampling of incoming lights doesn't take care about visibility so if bright(important) light areas is occluded you will spent your performance on sampling those occluded directions and it will increase variance.
There is some interesting paper called [LINK http://www.cs.ubc.ca/~heidrich/Papers/PG.06.pdf "Correlated Visibility Sampling for Direct Illumination"], It might be good if you will look at.
>> mrluzeiro wrote: in my scenario application I dont have easy way to setup the materials (or in other words: the file models of the components usually don't have material information)
I worked in such type of application once, those model components, PCB parts, must have some physical parameters and I think you can get physically based material properties from that(It might be not enough but you can add some parameters with some heuristically).

(L) [2015/09/01] [mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

Hello all,
Just show you the progress of my humble raytracing that I am working for KiCad (an opensource PCB EDA tool)
I almost finish to convert a board into raytracing shapes (i.e: polygons, triangles, cylinders, round segments, rings, disks, CSG, etc..)
Still no shading, the attached images are colored with normals.
No statistics yet, but a board like the one in the image can have around 100K objects.
I used a lot of opensource code pieces in the source, they are all credited.
Thanks also for this group forum and your inspiration!

(L) [2015/09/14] [franz] [Re: Ideas request for a specific raytracing application] Wayback!

Hi,
I was randomly browsing the forum when I stumbled upon this thread. Very interesting use case of raytracing.
Since I'm the founder and one of the core developers of appleseed, I thought I could chime in. Yes, appleseed is first and foremost a (shared) raytracing library. There are complete C++ and Python 2/3 APIs. The tools we ship (appleseed.cli, the command line batch renderer, and appleseed.studio, the graphical user interface for visualization and lookdev) use the same public C++ API as any other third party integration.
If you're interested in giving appleseed a try, please feel free to join our development mailing list and initiate a dialog there. We'll be happy to assist with the integration.
Best,
Franz

(L) [2015/09/14] [mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

>> franz wrote:Hi,
I was randomly browsing the forum when I stumbled upon this thread. Very interesting use case of raytracing.
Since I'm the founder and one of the core developers of appleseed, I thought I could chime in. Yes, appleseed is first and foremost a (shared) raytracing library. There are complete C++ and Python 2/3 APIs. The tools we ship (appleseed.cli, the command line batch renderer, and appleseed.studio, the graphical user interface for visualization and lookdev) use the same public C++ API as any other third party integration.
If you're interested in giving appleseed a try, please feel free to join our development mailing list and initiate a dialog there. We'll be happy to assist with the integration.
Best,
Franz
Hi Franz.
Thanks for your appreciation!
People here in the forum already pointed me appleseed as a reference.
I am just an occasional contributor on KiCad project and this experiences I am doing are in a separate branch. Still don't know if they will ever be merged or accepted one day. Hope so.
It means that, as far as I know KiCad project, there is an issue with KiCad currently that may block the addition of new libraries for the project: it is not based on plugins.
There is some plan to start remove some huge libraries already from the source code of the project (ex: boost) and some people start to thinking in some plugin types.
So the idea is not add much library overhead to the project. That why I am also a bit afraid because my experiments are already getting huge. So I hope that they come with some kind of plugins.
If KiCad would come with a good plugin system, someone could start a parallel project and use appleseed independent of the main kicad development.
Does appleseed supports different types of objects (spheres/cylinders, etc?) or just triangles?
Another possibility would be to generate / export to appleseed format and render in any other 3rd part application.
In any cases, I cannot do it alone or plan to engage alone in such type of new experiments. Maybe I can try to spread more this ideas and get more people in the project so something nice can be tried with appleseed!

(L) [2015/10/27] [mrluzeiro] [Re: Ideas request for a specific raytracing application] Wayback!

Hello all,
Here are some screenshots of the progress that I am working in a raytracing for the Kicad (PCB EDA tool)
[LINK https://meocloud.pt/link/aaf06e3f-e308-40c8-bddb-f8aa762b4a16/20151027_3d-viewer/]
(please download the image file if you want the full resolution)
I implemented an adaptive tracing to get some fast / draft while moving the board (so I can have some interactive rates)
For the final render I added a (CPU) screen space ambient occlusion shader to add a little more realism.
It takes some seconds (1..2.. 3s) to render (the quality version) in my 8 cpu laptop. It performs a (low quality) AA, some refractions and the shaders (SSAO and 5x5 blur to AO) that take a good part of the final rendering time.
It is OOP, no SIMD implementation, but there are other nice things such as BVH (from PBRT book), BVH frustum "ranged [packet] traversal", morton codes..etc
Attached is a example that clear shows the effect of the SSAO shader.
If anyone interested in the sourcecode, have a look at:
[LINK https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer]
Mario

Re: Ideas request for a specific raytracing application back

Board: Home Board index Raytracing General Development