Triangle sees triangle?

Started by
12 comments, last by Tree Penguin 19 years, 8 months ago
Hi, lets say i have a scene built up out of a few hundred triangles and i want to know if a triangle 1 'sees' triangle 2 (like there is a way to cast a ray from any point on triangle 1 to any point on triangle 2 that's not intersected by any other triangle). Is there an easy / fast way to determine it? I thought of casting rays and if one isn't intersected mark as true, if all (lets say 512 rays total) are intersected mark as false. The problem with that method is that it will be SLOW. So, any suggestions ?
Advertisement
'triangle see triangle' = general problem because it's basically if any point of the first triangle can see any point of the secocnd triangle.

You can render scene with camera placed on the first traingle and looking at the second traingle and then if you rendertarget contains white pixels then second traignle is visible.

I think orthogonal projection would do he trick
www.tmreality.com
Quote:Original post by tomek_zielinski
'triangle see triangle' = general problem because it's basically if any point of the first triangle can see any point of the secocnd triangle.

You can render scene with camera placed on the first traingle and looking at the second traingle and then if you rendertarget contains white pixels then second traignle is visible.

I think orthogonal projection would do he trick

Nah, that will be even slower then casting rays i think.
The problem is that i will have to do the test like 5000 times. It may take one or two hours total, that's no problem.
Hi,
It's the base of the radiosity lighting method, you can check all the links which exists on that subject...
Quote:Original post by Anonymous Poster
Hi,
It's the base of the radiosity lighting method, you can check all the links which exists on that subject...

Thanks! It is for a rendering engine so that will probably be what i'm looking for.
I described the method used in hardware accelerated radiosity, so no - It wouldn't be slower that CPU-only radiosty
www.tmreality.com
Nope, it's not.
I will explain it a bit further:

I just finished the diffuse lighting part of m rendering engine and i am now thinking of ways to implement reflections.

I want them to be as accurate as possible (so no ugly noise appears).
As i am working with lightmaps (not with pixels on the screen or anything, every triangle has its own lightmap) i thought of just casting rays from every texel of triangle 1 to every texel of triangle 2, which is slow and kind of related to radiosity.
The other solution would be casting rays from every reflective texel to see where it ends up (which isn't so accurate and maybe not even faster).
Anyway, as i think that first one is the only good solution and it's pretty slow. As there are probably only a few triangles that 'see' the reflective ones i would like to know if there's any accurate and fast way to see if they do.
Quote:
which is slow and kind of related to radiosity.

There is no way to do it in realtime that will be especially fast...the only ray tracers that are out there that both look nice and run fast must be run on super computers (there was a thing on NeHe that implements quake3 graphics using 100% accurate ray tracers, and requires something in the realm of a 12GHz procesdsor equivalent to be able to run).

So, basically, why not just do it in compile mode, let it be slow, and just save the results? That's how the regular lightmap is done anyway.

EDIT:
you could still use tomek's suggestion to 'cull' triangles. Look into the extension occlusion query (it's traditionally used to determine if rendering portals are visible or not...i.e in the doom3 alpha if you hit the button that shows portals, they are only activated (turn green) when the portal has at least some of its pixels visible to the eyepoint).
Why don't alcoholics make good calculus teachers?Because they don't know their limits!Oh come on, Newton wasn't THAT smart...
Quote:Original post by shadow12345
So, basically, why not just do it in compile mode, let it be slow, and just save the results? That's how the regular lightmap is done anyway.


What do you mean by compile time? The engine renders seperate frames of an animation, it get's the scene, the textures and everything else is calculated when the program runs.
As the data is only used once it's probably faster to calculate it when you need it (no loading and hd-space required).

Quote:Original post by shadow12345
you could still use tomek's suggestion to 'cull' triangles. Look into the extension occlusion query (it's traditionally used to determine if rendering portals are visible or not...i.e in the doom3 alpha if you hit the button that shows portals, they are only activated (turn green) when the portal has at least some of its pixels visible to the eyepoint).

I have thought of excluding triangles that face the other way and excluding triangles that are behind the texels. Anyway i suddenly came up with the stupid simple idea of first testing the triangles using their bounding circles and then doing the point-in-triangle test.
Quote:Original post by tomek_zielinski
'triangle see triangle' = general problem because it's basically if any point of the first triangle can see any point of the secocnd triangle.

You can render scene with camera placed on the first traingle and looking at the second traingle and then if you rendertarget contains white pixels then second traignle is visible.

I think orthogonal projection would do he trick

False, parts visible on one texel might not be visible on another texel because of angles and such, what you see with one eye might not be visible with the other.

This topic is closed to new replies.

Advertisement