Drawing conditional lines

[Santeri Piippo]

I'm using OpenGL for LDForge's renderer and I'm about stumped on to decide when to draw conditional lines. Actually rendering the part is no problem but how does a GL renderer take the control points into account?

For compiling objects glGenLists/glNewList/... is used and glCallList for drawing them. While it's not the most optimized approach, it works for something as simple as a single part.. at least for the simple ones. I've been considering using VBOs though.

[Travis Cobbs]

LDView computes which conditional lines to draw completely on the CPU. (It does so in background threads on computers with more than 1 CPU core.) Once it has calculated the indices of the "active" conditionals for a given frame, it draws them with glDrawElements(). You definitely don't want to use display lists for the conditional lines.

[Tim Gould]

This issue (including its friend at POVray) makes me chuckle. I find it quite funny that it's easier to make a 'true 3D' render on a GPU than a classic wireframe.

Tim

[Santeri Piippo]

Ah, bah... guess I'll have to keep drawing them as dashed lines for a while. GL is too headache-inducing to go after this.

Thanks anyway.

[Travis Cobbs]

It's worth mentioning that there are algorithms out there for GPU-accelerated outlining. These would probably work fine with LDraw parts (although they might require BFC in order to work right). However, I believe they would involve ignoring the conditional lines in the file, and using various tricks in the GPU to come up with the outline, so I'm not sure they would work with multi-colored edge lines.

[Santeri Piippo]

The main, perhaps only, reason for actually drawing conditional lines in LDForge is quickly previewing them so that the author could confirm that the conditional lines would behave properly, thus they'd have to be drawn exactly like the LDraw spec says.

[Travis Cobbs]

If LDForge only deals with parts, then calculating the conditionals every frame on the CPU isn't ever going cause a performance problem (even if you don't bother to try to optimize with multi-threading). Even with the 48x48 baseplate, LDView gets 480FPS with conditional lines enabled on my computer (and around 2000 with them disabled).

Mind you, calculating which ones to draw is a pain. However, because of this, the code inside LDView that calculates whether a particular conditional should be drawn is well-commented. You're welcome to copy it if you want. Take a look at TREShapeGroup:houldDrawConditional() here:

http://ldview.cvs.sourceforge.net/viewvc...iew=markup

Note: I think Don Heyse gave me the initial code that the LDView code is based on.

[Alex Taylor]

It's pretty trivial to do with a vertex-shader (or geometry-shader on newer OpenGLs). All calculations are handed off to the GPU, and are done on-the-fly at render-time, which means you can stick all the optional-lines in display-lists or VBOs without having to worry about which ones will eventually be visible.

[Roland Melkert]

Hi Alex, Long time no read

@Santeri

I use Alex' excellent approach in my LDCad, you can see the shader code in the resources folder of it's installation.

The geometry shader approach is the most efficient on paper but on older cards/drivers it's actually slower then the vs one.

The vs approach works on almost any gl platform, but it takes a whopping 5 attributes (incl pos) per vertex, and as a result wastes quite some memory and completely messes up your index re usage, But the performance you get is all all worth it

[Santeri Piippo]

Interesting - I'll have to give that a shot. Thanks for the suggestions.

On the subject of GL stuff, I've had some problems with alpha rendering as well, stuff seems to get rendered in the wrong order. I have no clue why it is doing this, maybe some of you have encountered this before?

[Roland Melkert]

This is because alpha blending is applied to the pixel color that's present at the time of rendering the transparent poly. If you draw something else later on that's further away gl will ignore it based on the z buffer.

To prevent this you need to render all solid things before you render any transparent stuff. You also might need to sort individual poly/parts when using multiple transparent colors in a single scene. If you don't do that the colors won't blend naturally.

[Steffen]

I found these links insightful about cond lines:

• http://www.ldraw.org/reference/specs/fileformat.shtml
  
• https://www.flickr.com/photos/anoved/540...5885422202
  
• https://www.flickr.com/photos/anoved/540...5885422202
  

[Tim Gould]

Done. Maybe edit your title back to something descriptive since those links do belong

[Nils Schmidt]

I already described a possible mathematical solution here.

I also use hierarchical bounding boxes to check the visibility of subfiles on the screen.
LDPartEditor does not calculate the conditional line visibility for subfiles (sub-subfiles...) which are out of the screen.
The first matrix product (viewport x modelview matrix) can be cached. Therefore, only four vector transformations, two substractions, additionally 8 substractions, 8 multiplications, 8 additions and a final multiplication are necessary to create the discriminant for conditional line visibility. You can cache the result, too.