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 / 10885
10884  |  10886
Subject: 
Re: POV-Ray help needed
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 26 Jun 2008 14:42:29 GMT
Viewed: 
9203 times
  
Travis Cobbs wrote:
A few things.

First of all, both the LDraw file format and the POV file format support
hierarchical compositions, so I think it's a good idea to leave things in their
original hierarchy.  So, instead of having a POV object for each part that is
made up entirely of one single mesh2 object, with all the geometry for the part,
it should instead contain a mesh2 object for all the type 3 and 4 lines in the
part, but then references to the part's primitives and subfiles (which
themselves are constructed in the same way).  This would significantly decrease
the file size of the generated POV file.

Actually I was planning to support both to see which approach renders
faster. Having the vertex and index data in memory, the mesh2 approach
was the easiest step to begin with. I only had to correct for quad ->
triangle conversion to get something usable in POV-Ray.


Secondly, primitive substitution helps a lot.  At the very least, I think you
should support primitive substitution for cylindrical primitives, since there
are so many studs.  This improves the final result noticeably.  If you're
interested, I have a class (in C++) that parses an LDraw filename and then
automatically determines if it is a primitive, and if it is a primitive,
extracts all the pertinant info from the filename.  (For example, if you feed it
4-4cyli.dat, it knows that it's a cylinder, and knows that the cylinder fraction
is 1.0.  2-4cyli.dat is recognized as a cylinder with a fraction of 0.5.)

Yes primitive substitution is on my to do list (for the recursive
approach, I don't see an easy way of doing it with the mesh2 approach).
But I wanted to get a 'simple' export on the road first.

I also have code in LDView that generates a POV camera statement that exactly
matches LDView's view (assuming the POV output has the same aspect ratio as the
LDView view).  If you're having trouble with your camera angle, you might be
interested in that code.

That could be interesting, My problem at the moment is indeed finding
the correct camera angle. Point is I do not (always) have access to
OpenGL during export so I have to recreate the camera with the eye, up
and lookat vectors I also us for gluLookAt. I also copy the 60 degree
FOV I use in gluPerspective.

But like said this does not give the wanted result, the 'zoom' is off. I
am now looking into using the OpenGL frustum as a starting point in
finding the angle.

As for material properties, I can't really help you much there.  Different
people have come up with different material properties for the various LDraw
colors with differing levels of apparent match to real life bricks.  The thing
is, different material definitions produce different results based on the render
settings.  Radiosity and HDR light field renders in POV can look very realistic,
but they can also be very slow to render.  And the material properties that look
best for those will probably not match the material properties that look best
for other lighting models.

Yes colors are largely a user thing, but I would like to supply a decent
'default' set of materials generated from the color palette used in
LD4DStudio. The application has a color configuration file which can be
merged with the ldraw config file to get the maximum amount of colors. I
was planning to add specific povray properties to my custom colors xml file.

One thing to do here is to give users the opportunity to include their own
custom include file at the top of your output.  Then, enclose all of your color
definitions in #if defined blocks, so that if the user wants to redefine the
colors, all they have to do is define them in their include, and then make the
appropriate declares to prevent your color definitions from being used.

The #if approach like used in L3P is a good idea, thanks. I will add
some optional settings to let users automatically include some custom
pov files.

--Travis

Thanks for your feedback.



Message has 1 Reply:
  Re: POV-Ray help needed
 
(...) I believe that POV's FOV is the horizontal field of view, while OpenGL's is vertical field of view. So you have to convert from one to the other (which I do in LDView). Set your rendering window in both the OpenGL view and the POV rendering to (...) (16 years ago, 26-Jun-08, to lugnet.cad.dev)

Message is in Reply To:
  Re: POV-Ray help needed
 
(...) A few things. First of all, both the LDraw file format and the POV file format support hierarchical compositions, so I think it's a good idea to leave things in their original hierarchy. So, instead of having a POV object for each part that is (...) (16 years ago, 25-Jun-08, to lugnet.cad.dev)

7 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