John VanSickle wrote:
> * Don't use full red against black; the color compression is not kind to 
> red-against-black edges.  A yellow roller coaster would work just as 
> well for test purposes.

Why is that?  I don't know much about the technical details of lossy 
compression.  Why would yellow on black work better than red on black?

> * Don't use a checkered plane, especially black and white.  A granite 
> pattern, scaled large, with softer colors, will compress just as much 
> with far less artifacting.

I knew from the start that the checkered plane wasn't a good idea.  I'm 
now using this to create some nice grass:

plane {
   y,  -1.0
   texture { pigment { granite color_map { [0 color <0,.2,0>] [1 color 
<0,.4,0>] } } }
   texture { pigment { bumps color_map { [0 color rgbt <0,1,0,0.6>] [1 
color rgbt <0,.6,0,0.6>] } scale 25 } }
}

Though I suppose I should get rid of the granite.  While it looks very 
nice, it creates a level of detail that would require too much data to 
show in a test render that I'm posting here.

> * If you're not using anti-aliasing, do so.  Smooth edges compress far 
> better than jagged ones.

All my current renders that I've posted use AA, but I'm currently 
rendering a longer section of track taken from a coaster I've actually 
designed, and since this is a test render, I want it to be somewhat 
fast.  Its been going for 16 hours now and is on frame 369, and its 
going to be 30 fps.

One of my biggest problems is the track ties.  I don't know an efficient 
method of spacing the track ties out an equal distance from each other, 
since the track is defined by beziers that will almost always be varying 
length.  I mentioned this in the original post.  The test I'm rendering 
right now only has the first drop (Which turns right 225 degrees while 
going down, then swerves left 45 degrees), the first hill which has a 
double-down (A drop that straightens out partway down it, then drops 
again), then a rising turn to the left.

At least, that's what its SUPPOSED to do...No Limits has its Z axis 
flipped compared to POV-Ray's, so the coaster comes out a mirror image.

Anyways, it currently takes 26 seconds to parse each frame because it 
calculates the locations of all the track ties every time.  I need to 
change that so it only does it on the first frame, saves the locations 
to a text file, then reads it back on all the other frames.

-DJ

Post a reply to this message