To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 6485
6484  |  6486
Subject: 
Re: LDGLite bug reports
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 15 Oct 2001 00:00:49 GMT
Viewed: 
376 times
  
In lugnet.cad.dev, Jacob Sparre Andersen writes:
I have played around with running LDGLite as a pure command line
tool by redirecting its output to a virtual X server (Xvfb).
This works fine once you figure out how to generate the
appropriate orientation matrices to compensate for unusual
aspect ratios, but with one combination of a MPD file and an
orientation matrix I run into problems with the near z clipping
plane.

Download

  http://jacob.sparre.dk/LEGO/By/Huse/Bunden_og_Kanden/butik.mpd

and try to run LDGLite with these parameters:

  ldglite -l3 -a-1.212,0,-0.702,-0.451,1.609,0.778,0.538,1.349,-0.928 -o0,-100
-s2.0 -w2.0 -mc butik.mpd

It is not the wierd look that is the problem (thats to compensate
for Xvfb's wierd aspect ratio), but the clipping of the door
upstairs. If you then try to move the near and far z clipping
planes:

  ldglite -z-4000 -Z4000 -l3
-a-1.212,0,-0.702,-0.451,1.609,0.778,0.538,1.349,-0.928 -o0,-100 -s2.0 -w2.0
-mc butik.mpd

LDGLite reports that it has changed the location of the z
clipping planes - "ZClip = (-4000, 4000)" - but the result
remains the same.

May I guess that the near z clipping plane can not be closer than
0?

Would it be practical to extend the "-o" argument with an
optional z offset to compensate for that?

Wow!  Lots of bugs reports all at once.  Where do I start?

I don't know what's up with xvfb the aspect ratio problem.  It seems
odd since you can reshape an ldglite window and the aspect ratio is
handled correctly.  I guess I'll have to get xvfb and start
experimenting with it.  Meanwhile the Mesa offscreen rendering code
is in CVS, but so far it just generates a blank image.  I suspect I
have some code that tells it to render in the back buffer which just
confuses the OSMesa buffer.  Another option for larger or oddly shaped
images is to use the tiled rendering option with a small window size.
This renders a large image sequentially as a series of tiles, each
the size of the window.  There are some (probably incomprehensible)
notes on how to use the -u tiled rendering option at the end of the
readme.txt file.

The near z clipping plane IS limited to non-negative numbers.  It is
the distance along the vector from the eye/camera to the model origin.
A negative number would put it behind the eye, which is illegal in
opengl.  I think the far Z number is also measured as a distance from
the eye/camera.  I think I set near z at 100 for 16 bit depth buffers
such as the default in Mesa.  (ldglite should tell you the bit depth)
Going much closer to the eye results in z-fighting.  But I think you
can get more depth bits in Mesa somehow.  (possibly a compile option?)

(0 = eye) ---> z ---------> Model origin -----------------> Z

You should be able to achieve what you want to do with the -o option
by using the -cc and -co options to move the location of the camera
(eye).  Unfortunately I really have to sort out the mess of coordinate
systems used for the camera/eye vs. the ldraw coords used in the model.
I'm open to suggestions on this.

As for compiling on the 64 bit alpha platform, all I can say is "where
do you get your hands on that kind of hardware"?  I'm building this on
a piece of junk!  I'll try to clean up all of the pointer conversion
warnings.  I admit I've been a bit lazy about that, but I suspect it
won't fix the problem.  It's more likely a structure alignment bug.
I don't suppose you could run the debugger on the core dump and send
me some screen shots of the stack trace and the local variables at the
point where it dies. :)

Don



Message has 1 Reply:
  Re: LDGLite bug reports
 
Don: (...) The tiling works fine, but it is extremely slow compared to rendering the whole image in one piece. (...) Those notes are quite easy to understand once you find them. ----- (...) Considering that we are considering parallel projections, (...) (23 years ago, 15-Oct-01, to lugnet.cad.dev)

Message is in Reply To:
  LDGLite bug report: Setting of z clipping plane without any effect
 
I have played around with running LDGLite as a pure command line tool by redirecting its output to a virtual X server (Xvfb). This works fine once you figure out how to generate the appropriate orientation matrices to compensate for unusual aspect (...) (23 years ago, 14-Oct-01, to lugnet.cad.dev)

4 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