The MASM Forum Archive 2004 to 2012
Welcome, Guest. Please login or register.
July 16, 2018, 02:21:15 PM

Login with username, password and session length
Search:     Advanced search
128553 Posts in 15254 Topics by 684 Members
Latest Member: mottt
* Home Help Search Login Register
+  The MASM Forum Archive 2004 to 2012
|-+  Specialised Projects
| |-+  High Performance Ray Tracing (Moderator: Mark_Larson)
| | |-+  RT'ing in 3D
« previous next »
Pages: [1] Print
Author Topic: RT'ing in 3D  (Read 12746 times)
vanjast
Member
*****
Posts: 1210

Daarrrrrr in die bos !!!


RT'ing in 3D
« on: June 29, 2009, 12:05:12 PM »

While going through all the tuts and methods, I get the impression that a lot of the algorithms are geared for a 2D flat screen with depth perception.

To me it seems like they missed the 3D thing, where for example the bounding box becomes more computationally intensive than using a bounding sphere. A sphere needs no 3D to 2D view frustrum translation, and each screen pixel (X,Y) increment angle is a function of the 3D view spherical coordinates. To me this is so obvious, but after reading all those theses, etc... I don't see this (maybe I'm blind).  green2

I'll carry on reading more stuff.
 Cool

Logged
NightWare
Member
*****
Gender: Male
Posts: 416


when dream comes true


Re: RT'ing in 3D
« Reply #1 on: June 30, 2009, 01:21:17 AM »

hmm, i don't follow this section, because i don't think that ray tracing has a near futur, in term of speed (and i don't speak of reflexion/refraction here...). but the fact that i don't believe it will be usefull soon doesn't mean it can't be interresting.

While going through all the tuts and methods, I get the impression that a lot of the algorithms are geared for a 2D flat screen with depth perception.
To me it seems like they missed the 3D thing
2d+1d = 3d. you can use many technics to represent it, but the basment is the same.

where for example the bounding box becomes more computationally intensive than using a bounding sphere. A sphere needs no 3D to 2D view frustrum translation
yes it needed (unless you don't need to position/texture it), your approach of spheres is the one used in video game for lightnings, coz speed is essential here (and no need for consistance). anyway, here sphere are faster because of pseudo optimizations, but when relexion/refraction will be added, you will understand how it's slower...

and each screen pixel (X,Y) increment angle is a function of the 3D view spherical coordinates.
also named ray tracing... so ? it's just a technic (different of the projections in video game).
Logged
vanjast
Member
*****
Posts: 1210

Daarrrrrr in die bos !!!


Re: RT'ing in 3D
« Reply #2 on: June 30, 2009, 01:51:43 PM »

Let me try say it another way  green2

1) We RT'ing in 3D space.
2) We have to either rotate (transform) all objects, or even faster - just rotate/transform our viewpoint.
3) All object, contained within a 'bounding sphere' (not cube or square), are transformed around their individual origins. The bounding sphere will improve the early out algorithm.
4) The pixel (X,Y) increment values (hence the individual rays) are calculated from the view transformation.
5) Only from here does the individual primary (and secondary) rays calculations start, still using the bounding sphere through the different ray layers while recursing 2) - 4).

To me it seems that the RT algorithms are OK for a tranformed view (5) , whereas above I'm trying to implement virtually the same thing, but with an non-transformed view. Hence the Sphere boundary which is the same in 3D or 2D, requiring no transformations which would help speed up the early-out thingy - By how much I'm not sure, but I don't think it's going to be slower than the box/cube method.
wink
Logged
NightWare
Member
*****
Gender: Male
Posts: 416


when dream comes true


Re: RT'ing in 3D
« Reply #3 on: June 30, 2009, 10:21:43 PM »

hmm, i'm not sure of what you trying to say, but :
- the sphere it's for the calculations (it's possible to use a variant, but it's just a variant... coz here you need a point of reference for your calcs),
- the cube exist for quickly eliminating what's out of the limits (depth, left, right, etc...).
it's why you must use a transformed view (2d+depth), not only to have a point of reference in your world, but also to quickly eliminate, for example, what's behind the point of view (all neg z),otherwise how are you going to quickly determinate if a work have to be made or not ? if you don't transform your point of view how are you gonna test the valid neg z from the wrong ones ? you can't test every points/polygons, it's why it's "made" previously with the transformed view, to make things easy after.

EDIT : ok now i see what you mean, in video game we use the z (depth) buffer, to avoid to recalc (most) things, i suppose this is what you talking about. but ray tracing is just another rendering method where others points have an influence on your (currently calculated) point, it's not exactly the same for video game. now combining the two methods can perfectly give a good result, here yes you can try...
« Last Edit: June 30, 2009, 11:37:57 PM by NightWare » Logged
vanjast
Member
*****
Posts: 1210

Daarrrrrr in die bos !!!


Re: RT'ing in 3D
« Reply #4 on: July 01, 2009, 01:00:34 AM »

I'm gearing this up for Xmos  ThumbsUp
Logged
vanjast
Member
*****
Posts: 1210

Daarrrrrr in die bos !!!


Re: RT'ing in 3D
« Reply #5 on: July 01, 2009, 01:26:41 AM »

To add to the above thing.. and really my 'sort of ambition'

I would like so see a working version of a flight simulator... my way
by my way I mean the 'real thing', the way it's supposed to be.
Xmos and RT are vehicles to achieve such objectives...
Xmos provide a very cheap way of achieving RT....... ect
 Cool BigGrin Roll Eyes



Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP The MASM Forum Archive 2004 to 2012 | Powered by SMF 1.0.12.
© 2001-2005, Lewis Media. All Rights Reserved.
Valid XHTML 1.0! Valid CSS!