To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.dev.macOpen lugnet.cad.dev.mac in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / Macintosh / 1055
1054  |  1056
Subject: 
Re: Bricksmith 2.4: Faster. Much Faster.
Newsgroups: 
lugnet.cad.dev.mac
Date: 
Wed, 16 Jun 2010 17:26:31 GMT
Viewed: 
35336 times
  
In lugnet.cad.dev.mac, Allen Smith wrote: snip
  
Bricksmith now recursively flattens the geometry for each referenced top-level part then sorts it according to primitive type (triangles, quads, lines). Since the primitives are sorted, each type can be enclosed in a single glBegin while display lists are compiled. I create a unique display list for each color variation of the part. Flattening and sorting the primitives allowed the display lists to perform vastly improved internal optimizations over what they were able to do with the unsorted data from the previous version of Bricksmith.

Unfortunately, all this is a bit beside the point because display lists are on their way out, deprecated, not even available on the iPhone, etc. You are supposed to be using VBOs and VAOs nowadays. Unfortunately I am not a 3D guru, wrote my program using obsolete methods to begin with, and it has taken me a while to plan a transition.

By the way, Bricksmith does not render conditional lines. I consider shading to be a sufficient substitute, and conditional lines sound difficult to optimize.

Allen

Thanks for the insight Allen,

I’m also not a 3D guru, but I like to fool around with it as much as anyone interested in 3d programming.

Your method is roughly the same as what LD4DStdudio does, except I use VBO to stuff whole high level parts in index-ed arrays. The indices are then grouped per color (16 being also a color) so a minimum of glcolor’s are needed during rendering. So it seems display lists aren’t ‘less’ then VBO at all to me.

Only problem with the highlevel part approach is you can’t support mirrored submodels higher up in the rendering tree (like eg the star destroyed mpd uses) cause it will mess up the normals. Or did you find a way around that?

Optimizations I was thinking of for my new renderer are using only triangles instead of 1 on 1 ld quads and triangles cause quads will be split by the driver anyway. (not sure if it’s actually faster doing it yourself but I’ll have to test that.)

The conditional lines are indeed a pain, normal lines can go in vbo/display lists much like the triangles but you have to test all conlines against the the current projection matrix for every redraw. I was planning to do this multithreaded (like LDView does).

Roland



Message has 1 Reply:
  Re: Bricksmith 2.4: Faster. Much Faster.
 
(...) One drawback with VBOs is that - unlike displaylists - you can't stick arbitrary GL calls in them. I'm using lists because I need to be able to put matrix operations in them as well as geometry. (...) Change the cull-face orientation ;-) (...) (...) (14 years ago, 16-Jun-10, to lugnet.cad.dev.mac, FTX)

Message is in Reply To:
  Re: Bricksmith 2.4: Faster. Much Faster.
 
(...) Hi Roland, Bricksmith now recursively flattens the geometry for each referenced top-level part then sorts it according to primitive type (triangles, quads, lines). Since the primitives are sorted, each type can be enclosed in a single glBegin (...) (14 years ago, 16-Jun-10, to lugnet.cad.dev.mac, FTX)

21 Messages in This Thread:





Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR