Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (715)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (788)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  raytracing idea: might it work?  (Read 2220 times)
0 Members and 1 Guest are viewing this topic.
Offline deepthought
« Posted 2013-02-04 00:45:51 »

I think if instead of shooting a ray out of each pixel, you could launch a trapezoid out of each scanline, and cut down on a crapload of intersection math. wherever each trapezoid collides, it should be split into 3 trapezoids: one leading to the face it collides with, 2 continuing on either side.

does anybody see any problems with this idea?

Mad Scientist
Offline Best Username Ever

Junior Devvie

« Reply #1 - Posted 2013-02-04 03:37:28 »

Can you draw a diagram? What's the problem with per pixel?
Offline ClickerMonkey

JGO Coder

Medals: 24

Game Engineer

« Reply #2 - Posted 2013-02-04 04:25:21 »

Are you talking about "raytracing" as in manual (done by you) raytracing? If so, using a trapeziod complicates things (trapezoidal intersection is more costly).

Have you ever heard of using gluPickMatrix?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Alan_W

JGO Knight

Medals: 8
Projects: 3

Java tames rock!

« Reply #3 - Posted 2013-02-04 07:03:49 »

Creating a pick list based on a scan line, then restricting the ray-trace (first collision only - no reflections) to checking that scan list would probably speed things up a bit, as you wouldn't keep collision testing for objects that weren't anywhere near the scan line.

It works for ray-casting.  I check each vertical scan line for movable objects that might intersect and make a list.  Then when rendering the scan line, I only need to check a subset of objects for collisions.

(Actually I firstly check that the object is in front, using dot product, then check it is within draw range.  If if passes these tests then it gets added to my first drawList (Same as for normal facet based 3D stuff).  Then for each scan line, I filter the first drawList, based on ray casting collisions, to create a second drawList of objects I need to overlay on the vertical scan line.  I have a third inner loop, where I draw the terrain at various depths and then overdraw the objects between the terrain billboards.  It is the existence of this last inner loop which makes it worthwhile for me, otherwise it wouldn't save any time.  Used in two of my 4k games)

I wonder what would happen if for true pixel-by-pixel ray-tracing, if for each visible object I did a collision check by vertical scan line and a separate collision check by horizontal scan line, resulting in each object having a screen draw box.  I suspect that the time taken for each pixel-ray to check the the intersection of the two lists would be longer than the time saved.  Maybe using a hash map... Not sure.  Interesting idea though I suspect the raytracing fraternity have already dug up any worthwhile optimisations.

Time flies like a bird. Fruit flies like a banana.
Offline Varkas
« Reply #4 - Posted 2013-02-04 09:43:47 »

It should help a bit. There is a technique called "vista buffer" which should be more efficient though, if you already implemented a bounding box tree:

Additionally POV-Ray uses systems known as vista buffers and light buffers to further speed things up. These systems only work when bounding is on and when there are a sufficient number of objects to meet the bounding threshold. The vista buffer is created by projecting the bounding box hierarchy onto the screen and determining the rectangular areas that are covered by each of the elements in the hierarchy. Only those objects whose rectangles enclose a given pixel are tested by the primary viewing ray.


You still need to calculate refracted and reflected rays per pixel though (at least if you have curved surfaces), also the texture and lightness. The intersection checks are suprisingly fast in many cases, compared to texture and light.

if (error) throw new Brick(); // Blog (german):
Offline Roquen
« Reply #5 - Posted 2013-02-04 11:51:46 »

I'd say that for many years now folks have banged their heads on various global illumination models and that a review of the major ones is the way to go if you want to bang out your own.

(EDIT: isn't exhaustive, but's a good start)
Offline deepthought
« Reply #6 - Posted 2013-02-04 14:42:26 »

afterwards each shape can be decomposed into rays for rasterization.
the idea is that you can cut down on intersection math by doing intersection tests on a slice of the frustum corresponding to each scanline.

i had originally come up with an idea similar to beam tracing, but i didn't know it was called beam tracing,so googling "volume tracing" didn't get any results. it looks like this should work.

Mad Scientist
Offline Varkas
« Reply #7 - Posted 2013-02-04 14:52:51 »

If you have polygon-faceted surfaces, raytracing isn't the best rendering method IMO. Raytracing can only excel if you have mathmatically defined bodies (sphere, cylinder, plane, box, prism) - e.g. instead of approximating a sphere with a 500 triangle mesh, you have a real sphere (and only one intersection check for the sphere).

if (error) throw new Brick(); // Blog (german):
Offline Roquen
« Reply #8 - Posted 2013-02-04 16:39:59 »
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

CopyableCougar4 (223 views)
2017-03-24 15:39:42

theagentd (205 views)
2017-03-24 15:32:08

Rule (265 views)
2017-03-19 12:43:22

Rule (247 views)
2017-03-19 12:42:17

Rule (252 views)
2017-03-19 12:36:21

theagentd (270 views)
2017-03-16 05:07:07

theagentd (267 views)
2017-03-15 22:37:06

theagentd (194 views)
2017-03-15 22:32:18

theagentd (188 views)
2017-03-15 22:31:11

ral0r2 (167 views)
2017-03-03 11:52:41
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!