> I'm currently working on a program that converts a Minecraft world into a
> POV-Ray scene, and I'm having real trouble with water.
>
> To make water blocks act like a solid object so that I don't see the sides of
> each block, I take all the water blocks in the world and put them into a CSG
> merge object, which in theory should make them solid.  Unfortunately, it isn't
> working out that way.
>
> If each block in the merge is exactly 1 unit wide, then I get lots of odd pixels
> where the water meets the land underwater.  This is understandable, since the
> water block edge is coincident with the land block.  So as a work-around, I
> tried making each water block slightly large (1.02 blocks wide), but this
> creates odd seams at the surface of the water.
>
> Example renders are at http://imgur.com/a/rCDCG
>
> A couple notes about my scene:
> - Vertical runs of the same block type are saved as a single tall box object to
> reduce the number of objects in the scene.
> - The hole in the world is from an optimization that stops looking for blocks
> below a certain y-coordinate, again, to reduce objects.
>
> Any ideas how to fix the coincident surface problem where the water meets land
> without create a coincident surface problem at the surface of the water without
> manually creating a mesh?
>
>

Looking at your sample, you could use a single large block for the 
water, or even a simple plane.
A large block would be dimentioned to cover the surface of the water 
area and be thick enough to reatch the bottom of the "lake".

If you need/want to have dry openings, you'll need to cut some holes 
using a difference.

Another way would be to make some stacked prisms, one for each layer and 
merge them. That way, you don't need to cut holes, but would get longer 
rendering times.




Alain

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Sohcahtoa wrote:
>
> > I tried making each water block slightly large (1.02 blocks wide), but this
> > creates odd seams at the surface of the water.
>
> If I understand correctly what your are doing, you get a 0.04
> unit wide strip of coincident surfaces at the top (and bottom)
> of the surface where those faces overlap slightly
>
> So you may need to introduce 4 heights/levels for each group
> of four neighboring cubes (you can try a checker-board pattern
> first to see if this is the cause of the problem but it will
> still have overlapping corners).

Yeah, I did a checkerboard pattern of two heights and it fixed the problem.
Oddly enough, I don't have any coincident surface artifacts at the corners like
I would expect.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> Looking at your sample, you could use a single large block for the
> water, or even a simple plane.
> A large block would be dimentioned to cover the surface of the water
> area and be thick enough to reatch the bottom of the "lake".
>
> If you need/want to have dry openings, you'll need to cut some holes
> using a difference.
>
> Another way would be to make some stacked prisms, one for each layer and
> merge them. That way, you don't need to cut holes, but would get longer
> rendering times.

In that sample scene, yes.

Are you familiar with the game Minecraft?  I'm writing a program that converts a
world created in Minecraft into a POV-Ray scene.  Where the water blocks are can
be somewhat random, and not necessarily in large chunks that can easily be
turned into a single large box or plane.  Bodies of water can be as small as a
single block, or spanning miles across.  Their shape will vary just as much.

Post a reply to this message

> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> Sohcahtoa wrote:
>>
>>> I tried making each water block slightly large (1.02 blocks wide), but this
>>> creates odd seams at the surface of the water.
>>
>> If I understand correctly what your are doing, you get a 0.04
>> unit wide strip of coincident surfaces at the top (and bottom)
>> of the surface where those faces overlap slightly
>>
>> So you may need to introduce 4 heights/levels for each group
>> of four neighboring cubes (you can try a checker-board pattern
>> first to see if this is the cause of the problem but it will
>> still have overlapping corners).
>
> Yeah, I did a checkerboard pattern of two heights and it fixed the problem.
> Oddly enough, I don't have any coincident surface artifacts at the corners like
> I would expect.
>
>
As those are small, only 0.04 squares, you may miss them easily.

Post a reply to this message

> Alain <kua### [at] videotronca> wrote:
>>
>> Looking at your sample, you could use a single large block for the
>> water, or even a simple plane.
>> A large block would be dimentioned to cover the surface of the water
>> area and be thick enough to reatch the bottom of the "lake".
>>
>> If you need/want to have dry openings, you'll need to cut some holes
>> using a difference.
>>
>> Another way would be to make some stacked prisms, one for each layer and
>> merge them. That way, you don't need to cut holes, but would get longer
>> rendering times.
>
> In that sample scene, yes.
>
> Are you familiar with the game Minecraft?  I'm writing a program that converts a
> world created in Minecraft into a POV-Ray scene.  Where the water blocks are can
> be somewhat random, and not necessarily in large chunks that can easily be
> turned into a single large box or plane.  Bodies of water can be as small as a
> single block, or spanning miles across.  Their shape will vary just as much.
>
>

I've heard/read a good deal about it, but never played it.

If you use a plane for the water, it's easy to cut holes in it's 
surface, just use a clipped_by{box{Corner1, Corner2 inverse}}
This will punch a hole without any side as you would with a difference.

Once the hole is made, you don't need to bother with the shape of the 
underground part.

A single plane can take care of all your water areas, no mather how 
large, what shape or number as long as they are at the same level. I 
don't know if you can have water blocks on a hill or down a valey... but 
some prism may do the trick.



Alain

Post a reply to this message

Am 07.03.2013 02:55, schrieb Alain:

> A single plane can take care of all your water areas, no mather how
> large, what shape or number as long as they are at the same level.

... and here the trouble begins ;-)

Post a reply to this message

"Sohcahtoa" <kil### [at] yahoocom> wrote:
> I'm currently working on a program that converts a Minecraft world into a
> POV-Ray scene, and I'm having real trouble with water.
>
> To make water blocks act like a solid object so that I don't see the sides of
> each block, I take all the water blocks in the world and put them into a CSG
> merge object, which in theory should make them solid.  Unfortunately, it isn't
> working out that way.
>
> If each block in the merge is exactly 1 unit wide, then I get lots of odd pixels
> where the water meets the land underwater.  This is understandable, since the
> water block edge is coincident with the land block.  So as a work-around, I
> tried making each water block slightly large (1.02 blocks wide), but this
> creates odd seams at the surface of the water.
>
> Example renders are at http://imgur.com/a/rCDCG
>
> A couple notes about my scene:
> - Vertical runs of the same block type are saved as a single tall box object to
> reduce the number of objects in the scene.
> - The hole in the world is from an optimization that stops looking for blocks
> below a certain y-coordinate, again, to reduce objects.
>
> Any ideas how to fix the coincident surface problem where the water meets land
> without create a coincident surface problem at the surface of the water without
> manually creating a mesh?

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.

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

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

Regards,
A.D.B.

Post a reply to this message

"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