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 / * (-5)
Subject: 
Re: Bricksmith 2.5: More performance improvements
Newsgroups: 
lugnet.cad.dev.mac
Date: 
Sat, 30 Apr 2011 17:18:03 GMT
Viewed: 
21010 times
  
Thanks Allan!


Subject: 
Bricksmith 2.5: More performance improvements
Newsgroups: 
lugnet.announce, lugnet.cad, lugnet.cad.dev.mac
Followup-To: 
lugnet.cad.dev.mac
Date: 
Sat, 30 Apr 2011 03:04:40 GMT
Highlighted: 
(details)
Viewed: 
36388 times
  


Bricksmith 2.5 adds the following features:
  • Multi-threaded file parser (10.6 64-bit only)
  • Inlined primitives drawn with faster optimized structures
  • Direct primitive vertex interaction
  • Cursor-centric zooming
  • Supports 3DConnexion mice for part orientation
It also fixes the following bugs:
  • Fixed situation in which all viewports could disappear
  • Fixed preserving perspective/orthographic view between launches
  • Magnification trackpad gesture is smoother
Bricksmith 2.5 offers several more speed improvements; notably, it completely expunges the obsolete and slow rendering method which was hitherto used to draw inlined parts. Models which use inline parts could see substantial improvements. (Datsville is a good example.)

Also new to Bricksmith is the long-awaited ability to reshape primitives using onscreen handles, rather than typing in vertex coordinates.

Bricksmith requires Mac OS X 10.5 or later, and may be download it at http://bricksmith.sourceforge.net/. It is both Intel and PowerPC native.

Sincerely,
Allen Smith


Subject: 
Re: Bricksmith 2.4: Faster. Much Faster.
Newsgroups: 
lugnet.cad.dev.mac
Date: 
Fri, 18 Jun 2010 10:22:50 GMT
Viewed: 
35435 times
  
In lugnet.announce, Allen Smith wrote:
  

Bricksmith 2.4 adds the following features:
  • Drawing speed improvements of up to 1200%
  • 64-bit native on Mac OS X 10.6
  • Viewports fill their entire frame
  • Supports displaying the newly-standardized direct RGB color syntax
  • Supports displaying legacy blended colors from the original LDRAW
  • Saved files are formatted in traditional LDraw text style instead of fixed-width columns
It also fixes the following bugs:
  • Fixed part selection failures for certain indirectly-referenced objects
  • Eliminated several extra redraws
You read that right: Bricksmith 2.4 is over ten times faster than Bricksmith 2.3 on a computer with a good graphics card. (Even with a woefully underpowered graphics card, you’ll still see a huge improvement.) Bricksmith 2.4 actually achieves a faster framerate than LDView on my computer. Now you can enjoy real-time interaction with models containing thousands of pieces!

Bricksmith requires Mac OS X 10.5 or later, and may be download it at http://bricksmith.sourceforge.net/. It is both Intel and PowerPC native.

Sincerely,
Allen Smith

Great !!!!

One request can you make it posible to edit inserted minifigures with minifig generator ?

Thanks


Subject: 
Re: Bricksmith 2.4: Faster. Much Faster.
Newsgroups: 
lugnet.cad.dev.mac
Date: 
Wed, 16 Jun 2010 22:52:23 GMT
Viewed: 
35653 times
  
In lugnet.cad.dev.mac, Alex Taylor wrote: snip
  
   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?


Change the cull-face orientation ;-)

snip
   Alex

Duh, I was over thinking it big time. Thinking scaling etc would f-up the normals, but with mirroring they will stay the same length. So you are right all I have to do is check if it’s an ‘mirror’ matrix and then change the OpenGL culling direction for all the subparts.

Thanks.


Subject: 
Re: Bricksmith 2.4: Faster. Much Faster.
Newsgroups: 
lugnet.cad.dev.mac
Date: 
Wed, 16 Jun 2010 20:14:54 GMT
Viewed: 
35469 times
  
In lugnet.cad.dev.mac, Roland Melkert wrote:
   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.


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.


   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?


Change the cull-face orientation ;-)


   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.)


I can’t say I’ve noticed the difference myself, but I suspect it’ll depend on the hardware and drivers as much as anything.


   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).


See my previous post :-) Offload the grunt-work to the graphics-card, and it flies!


Alex



Next Page:  5 more | 10 more | 20 more

Redisplay Messages:  Brief | Compact

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