[Bf-committers] CVS commit: blender/source/blender/blenkernel BKE_booleanops.h blender/source/blender/src booleanops.c

[Laurence Bourn]

Hey Daniel,
Things are a bit slow at work right now (the joys of working for a company
who make money!-). I was looking into fudging the vertex normals into the
boolean operation last night, however I was getting confused by where the
flags are kept to indicate a mesh or face is smooth.

The only thing I see in DNA_Mesh_blaaa.h is a MVert with 3 shorts indicating
the normal and a flag in MFace (maybe TFace) that has a SMOOTH bit in it.
So...

Do I check to see if a face is smooth by checking this bit? (Didn't seem to
work last night - especially for objects that do not have TFaces???) 
If it is smooth extract the vertex normals from the faces MFace.
If its not smooth compute a normal for the face on the fly.

This was the plan but I soon got wholly confused by the Mesh situation -
perhaps you can indicate what to do/ where to look. 

I guess a consequence of this design is that there are no crease edges
supported in blender unless you dup the vertices on the crease edge? 

Shed light and pierce the fog shrouding the mysterious sources o Master.
Cheers,
Laurence. 

--------------------------------------------

Yah loza, why didn't you do it that way!

Get cracking mate!

--- Laurence Bourn <LBourn@medis.nl> wrote:
> Umm, no.
> However I have some ideas on how the current implementation could be
coerced
> into something similar.
> 
> Basically the algorithm falls in 3 major pieces.
> 1) Efficiently find intersecting polygons or (so a rough set including all
> the intersecting polygons is a good start)
> 2) Split all such polygons with their spplitters from the other object
(The
> crucial part here is you can do this in any order) 
> 3) classify all the polygons in the new split object as either in or out
the
> other object. Using the fact that they are either in or out and not
> straddling. 
> 
> This differs from the current implementation only in step 2. Where we used
a
> BSP tree. We can still use a BSP tree for parts 1 and 3 (infact the
current
> code does exactly the first step). Step 3 is pretty easy to. Just a ray
BSP
> tree intersection test and a cunning neighbourhood flood fill to speed
> things up a bit. 
> 
> In fact this is probably a bit easier todo than the current implementation
> and you are guarenteed only to split polygons only when it's absolutely
> necessary (well give or take a few cases). 
> 
> Why I didn't do it this way? I must have been mentally confused by the
> amount of cool Jazz Strubi used to play on his NaN office piano!
> 
> Unfortunately I don't have much time at all for this kind of stuff but it
> would be nice to finally slay this beast once and for all.
> 
> Cheers,
> Laurence.
> 
> 
> 
> -----Original Message-----
> From: LarstiQ [mailto:larstiq@larstiq.dyndns.org]
> Sent: maandag 24 maart 2003 17:33
> To: 'bf-committers@blender.org'
> Subject: Re: [Bf-committers] CVS commit:
> blender/source/blender/blenkernel BKE_booleanops.h
> blender/source/blender/src booleanops.c
> 
> 
> On Mon, Mar 24, 2003 at 05:17:59PM +0100, Laurence Bourn wrote:
> > Hiya Daniel,
> > Good to see you working on the Sauces hombre!
> > 
> > Vertex normals on boolean mangled meshes look bad coz the polygons in
the
> > neighbourhood of the intersection between the objects are of poor
quality
> > (long thin etc). It is much better to make the boolean operation itself
> > compute a new vertex normal each time it splits a face. It shouldn't be
> that
> > hard to convince the boolean op stuff in intern to do this. Maybe I
should
> > do it? All that BSP code was such a bad idea for doing boolean ops much
> > better to use the algorithm here:
> > 
> >
>
<http://www.flipcode.com/cgi-bin/msg.cgi?showThread=13November2000-Construct
> > iveSolidGeometry&forum=askmid&id=-1>
> 
> That looks good to me, also a bit of work tho :) Do you want to
> implement all that?
> 
> LarstiQ
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers


=====
daniel dunbar
daniel@zuster.org
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://www.blender.org/mailman/listinfo/bf-committers