# ROAM

This topic is 4948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm having a shot at implementing the ROAM algorithm, but there's one little bit that I'm slightly confused about: The algorithm in the paper says "While T is not the target size/accuracy, or the maximum split priority is greater than the minimum merge priority { "... Now, the target size/accuracy bit is obvious, but what is the purpose of the second clause, about maximum split priority vs minimum merge priority? What difference does that make? Thank you for your patience, Andy [Edited by - AndyGeers on April 29, 2005 4:50:43 AM]

##### Share on other sites
Well whilst I'm at it...

I'm also confused about why you would set the priority of triangles behind the near clipping plane to an artificial maximum - wouldn't that mean that every time you pop the maximum triangle off the split queue it's always likely to be behind the camera and hence stupid to split it?

P.S. People know what I'm talking about by ROAM, right?

##### Share on other sites
there is som threshold between the minimum merge priority and the maximum split priority that is "ideal", that means: if both queues keep "out" of this priority, no error metrics are violated. although you can tesselate even "more ideal" (by tesselating until both your queues are empty), the point at which priorities don't overlap happens to be the point at which your tesselation is accurate enough.

the priority of triangles behind the near plane has to be minimal (not maximal, as you stated, maybe a typo in the paper?), else they would be split. giving them min priority makes it likely for them to be merged.

##### Share on other sites
I knw that sounds reasonable, what you are saying about it being a typo, but seriously, I have checked with other stuff the author's have put out, and it really does mean maximal. I just don't get how it works...

##### Share on other sites
hmmm... this is a bit weird to me. my paper (http://www.llnl.gov/graphics/ROAM/roam.pdf) says minimum priority (page six, "View frustum").

but maybe you have some other paper/implementation at hand.
it makes sense to give them a higher priority, though. this would lead to pre-tesselating the area around the camera in order to make fast camera sweeps possible. but maximum priority is still nonsense, since triangles outside the frustum might split while the ones inside the frustum are still sub-optimal.

maybe your paper describes the priorities the other way round, that is, the minimum priority triangle gets split first and merged last?

P.S. on my page (http://www.robertsprojects.net/opengl/opengl.html), i have a split-only implementation for download... i use precalculated nested world-space bounds in order to calculate the split priorities. maybe you can take some use of it :)

##### Share on other sites
I'm sorry, I should have made it clearer: I'm talking about the bit in section 6.2 Geometric Screen Distortion, where it says (and I'm quoting from the version you just linked) "If a wedgie extends behind the near clipping
plane, the triangle’s priority is set to an artificial maximum
value and the distortion-bound computation is skipped."

I'm using the same paper as you, in which it is the maximum split queue priority that is used as the next triangle to split.

##### Share on other sites
The passage you quoted says "if a wedgie _extends_ behind the near clipping plane".
i think the idea is basically: you can't compute the error metric of a wedgie that crosses the near plane, since you can't project it onto the near plane in order to get screen space distortion. (well, you can, but this would require clipping a polyhedron which is too expensive)
this is why he safely assumes that it has maximum priority and thus will be refined in every case.
imho this has nothing to do with triangles being located behind the near plane, since
1. he would have written "if a wedgie lies completely behind..."
2. there would be no need to write the whole idea two times, since he explains optimizations concerning the frustum in 6.4 (saying the priority has to be min).

##### Share on other sites
Interesting...

I just assumed he said "extends" to include cases where only one or two vertices are behind the near plane as well as those cases where it is entirely behind. But I'll give that a go and see what happens

1. 1
Rutin
38
2. 2
3. 3
4. 4
5. 5

• 11
• 9
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633350
• Total Posts
3011473
• ### Who's Online (See full list)

There are no registered users currently online

×