"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> I would think it would be easiest to convert each mass of different block types
> into a single mesh by mapping the corner vertices.  make each mass smaller than
> it has to be by some tolerance value.  The problem I see with this is changes in
> ior when going from water to air, it might make the blocks under the water
> render improperly.

I'm starting to consider doing this.

> One thing you could try is shifting water vertices down and outward, so that
> they pass a little under the surface of surrounding blocks.

I mentioned in another post in this thread that I found that if I offset every
other water box vertically by a tiny amount in a checkerboard-like fashion it
solves the artifact problem.

> Are you planning to model everything, or only the surface?  Your conversion
> files will be awfully large if you model everything.

I wrote a flood-fill type of algorithm that searches to only find the blocks
that are visible above the surface.  However, a 600x600 world still ends up with
over 600,000 blocks.  The POV file ends up taking over 15 minutes to parse.

Post a reply to this message

"Sohcahtoa" <kil### [at] yahoocom> wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> > I would think it would be easiest to convert each mass of different block types
> > into a single mesh by mapping the corner vertices.  make each mass smaller than
> > it has to be by some tolerance value.  The problem I see with this is changes in
> > ior when going from water to air, it might make the blocks under the water
> > render improperly.
>
> I'm starting to consider doing this.
>
> > One thing you could try is shifting water vertices down and outward, so that
> > they pass a little under the surface of surrounding blocks.
>
> I mentioned in another post in this thread that I found that if I offset every
> other water box vertically by a tiny amount in a checkerboard-like fashion it
> solves the artifact problem.
>
> > Are you planning to model everything, or only the surface?  Your conversion
> > files will be awfully large if you model everything.
>
> I wrote a flood-fill type of algorithm that searches to only find the blocks
> that are visible above the surface.  However, a 600x600 world still ends up with
> over 600,000 blocks.  The POV file ends up taking over 15 minutes to parse.

You could try breaking the file into several smaller files -- say 10x10 chunks
square?  Or more, if you're comfortable with it -- and render each one
separately via batch file.

Regards,
A.D.B.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> You could try breaking the file into several smaller files -- say 10x10 chunks
> square?  Or more, if you're comfortable with it -- and render each one
> separately via batch file.
>
> Regards,
> A.D.B.

I don't see how that could reduce parse times.  It'd still have the parse the
same amount of data.

The best I can really do is just reduce the amount of the world my program
exports to the POV file.  So far, I only do this based on distance from a
defined point, which isn't really that good of a solution.  Ideally, I'd define
a point where the camera is and a direction the camera is pointing, then only
export geometry within a cone pointing in that direction, with some extra nearby
blocks included to make sure radiosity gets sampled well enough.

Post a reply to this message