POV-Ray : Newsgroups : povray.off-topic : povray vs. blender: blender doesn't do booleans w/ heightfields well. Server Time
7 Sep 2024 05:10:48 EDT (-0400)
  povray vs. blender: blender doesn't do booleans w/ heightfields well. (Message 1 to 7 of 7)  
From: gregjohn
Subject: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 14 Aug 2008 12:10:00
Message: <web.48a458b0c46418840d56c170@news.povray.org>
I've been experimenting with blender.  I spent a couple weeks of hobby time
trying to do Boolean operations on heightfields in blender.  (Except in
blender, the terminology is meshes to which a  Displacement Modifier has been
applied.)  I tried to use a box to cut a heightfield and just ran into lots of
failure, locked up screens, and things poofed out in ways that didn't make
sense.

Funny thing is I had been about to suggest to some folks that they use blender
in a professional setting to do this.  But I tried the same operation in
povray, and it worked the first time (ten minutes of coding from a pre-existing
heightfield SDL I'd written earlier).

Fascinating.


Post a reply to this message

From: stbenge
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 15 Aug 2008 14:41:23
Message: <48a5cdd3@news.povray.org>
gregjohn wrote:
> I've been experimenting with blender.  I spent a couple weeks of hobby time
> trying to do Boolean operations on heightfields in blender.  (Except in
> blender, the terminology is meshes to which a  Displacement Modifier has been
> applied.)  I tried to use a box to cut a heightfield and just ran into lots of
> failure, locked up screens, and things poofed out in ways that didn't make
> sense.
> 
> Funny thing is I had been about to suggest to some folks that they use blender
> in a professional setting to do this.  But I tried the same operation in
> povray, and it worked the first time (ten minutes of coding from a pre-existing
> heightfield SDL I'd written earlier).
> 
> Fascinating.

When you tried the boolean operation in Blender, did the deformed mesh 
still have the deform modifier attached to it? Did it have multires 
enabled? What about subdivision surfaces? It's best to apply all those 
first, and then decimate the mesh before trying anything fancy.

Blender is a different beast, and must draw to the 3D preview window as 
well as be able to render the final image. You can use bounding box mode 
for the preview, or wire frame mode. These are just ideas. I still 
manage to crash Blender every day I play with it :/

Sam


Post a reply to this message

From: gregjohn
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 16 Aug 2008 09:00:00
Message: <web.48a6cf1f444429334d207310@news.povray.org>
stbenge <THI### [at] hotmailcom> wrote:

>
> When you tried the boolean operation in Blender, did the deformed mesh
> still have the deform modifier attached to it? Did it have multires
> enabled? What about subdivision surfaces? It's best to apply all those
> first, and then decimate the mesh before trying anything fancy.
>
> Blender is a different beast, and must draw to the 3D preview window as
> well as be able to render the final image. You can use bounding box mode
> for the preview, or wire frame mode. These are just ideas. I still
> manage to crash Blender every day I play with it :/
>


I had already Applied the Displacement Modifier before attempting a Boolean.
Can you give me more clues about multires?
What good would subdivision surfaces do? -- I can only imagine harm, and I
wasn't using them.

Ultimately, I was looking for a structure that:

i) can take inputs from a bitmap (povray: heightfield; blender: displacement
mod).

ii) when cut by a difference, has 3D volume to it.  (a heightfield by itself in
povray is just a surface; cut it and you've got half an "empty" surface.  Thus,
I was trying to cut a cube/box with a heightfield.)

iii) takes negative or positive shapes (povray doesn't care whether you've got a
bunch of black circles on white background or white on black;  blender gives
freaky results for one of these two).


So far, povray worked flawlessly in i), ii), and iii).
The only limitation is the lack of the real-time GUI display if someone wants to
grab and rotate it.

BUT, in this scenario,  for folks who know neither povray nor blender, it may be
hard for them to produce these cutaways with either app.  Unless there's an
expert around to help them.


Post a reply to this message

From: stbenge
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 16 Aug 2008 19:56:04
Message: <48a76914@news.povray.org>
gregjohn wrote:
> 
> I had already Applied the Displacement Modifier before attempting a Boolean.
> Can you give me more clues about multires?
> What good would subdivision surfaces do? -- I can only imagine harm, and I
> wasn't using them.

The multires option in this case probably wouldn't be the best thing to 
use. Subdivision surfaces give you more control, and you can adjust it 
to give you more or less detail before you make it permanent.

Here's what I did to get cube/height-field booleans to work in Blender:

1) added a mesh plane (the future height field)
2) added a subsurf modifier with the Simple Subdivision method, not 
Catmull-Clark
3) added a displace modifier
4) applied both modifiers to the plane, thus making the changes permanent
5) added and applied a decimate modifier to reduce the number of 
triangles in the plane, while trying to keep a good amount of detail
6) moved the object to another layer
7) added a cube to layer 1 and then added a boolean modifier pointing to 
the modified plane
8) applied the boolean to the cube (making it permanent) so Blender 
didn't take forever to recalculate it every time I tried to do something

It's best to do all the complex operations first, and then apply them 
before attempting a boolean operation. Also, boolean operations don't 
make the second object invisible, so to see the effect more clearly you 
have to make it invisible yourself. The easiest way to do this is simply 
to move it into an unchecked layer.

High-triangle meshes combined with boolean operations can be very slow 
to compute, and extremely memory-intensive. This is why I suggested that 
you decimate the "height field" to reduce the total number of triangles. 
You can also delete faces that you know won't affect the outcome. The 
most likely reason for Blender crashing on you is that somehow you ended 
up using all your RAM. I crash Blender this way more than any other :(

I hope this helps~

Sam


Post a reply to this message

From: gregjohn
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 17 Aug 2008 09:15:01
Message: <web.48a82386444429334d207310@news.povray.org>
stbenge <THI### [at] hotmailcom> wrote:
> Here's what I did to get cube/height-field booleans to work in Blender:
>
> 1) added a mesh plane (the future height field)
> 2) added a subsurf modifier with the Simple Subdivision method, not
> Catmull-Clark
> 3) added a displace modifier
> 4) applied both modifiers to the plane, thus making the changes permanent
> 5) added and applied a decimate modifier to reduce the number of
> triangles in the plane, while trying to keep a good amount of detail
> 6) moved the object to another layer
> 7) added a cube to layer 1 and then added a boolean modifier pointing to
> the modified plane
> 8) applied the boolean to the cube (making it permanent) so Blender
> didn't take forever to recalculate it every time I tried to do something


That's one very useful insight: the idea of mesh plane (four points) and then
subsurf it until you get your image to show up as you like it. I was previously
adding a grid.  Decimation is in general a good practice, but for my scenario,
even a 0.78 decimation ruined the surface (caused me to lose features), so I
didn't apply.

After trying out your advice, however, I have to report that blender FAILS the
test. It cannot make both positive and negative surfaces that are cuttable.

BACKGROUND:  Suppose someone is going to insert carrot sticks vertically in an
array in ice, and then wants to be able to get cut-away views of the ice/carrot
arrangement.   The problem for this case is that you have to be able to take as
an input the position of the carrot sticks as a bitmap (white circles on dark
field).

Because of the way blender does booleans,  I am required to have both an "ice
w/holes" object and a "carrot stick assembly" object if I want to be able to go
back in and make cuts.

From a week of experimentation, and a morning of following your advice, making
one of those inexorably locks up blender.   :-(


Post a reply to this message

From: Saul Luizaga
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfields well.
Date: 21 Aug 2008 02:06:27
Message: <48ad05e3$1@news.povray.org>
So, logical conclusion is... POV-Ray ROCKS!


Post a reply to this message

From: stbenge
Subject: Re: povray vs. blender: blender doesn't do booleans w/ heightfieldswell.
Date: 21 Aug 2008 16:57:01
Message: <48add69d@news.povray.org>
Saul Luizaga wrote:
> So, logical conclusion is... POV-Ray ROCKS!

For most things, yes, it does :)

Blender is becoming a more capable all-around modeler/renderer, and is 
useful for things in which POV-Ray is weak at doing. Blurred 
reflection/refractions, hair, AO, cloth, those sorts of things. It still 
can't do radiosity, but it's really only a matter of time.

POV-Ray will always be a unique and useful tool in my toolbox. You can 
script with it, after all. Scripting opens the door to almost anything, 
and the more more features added to POV, the more freedom one has with 
scripting.... (I suddenly drag myself off my soap box)

Sam


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.