[Bf-committers] Booleans

[Ton Roosendaal]

Hi Theodore,

I think it's wise to go in small steps with this projects.

- Most evidently we first need a good CSG operation which can be used  
as a modeling tool. A first implementation can be based on current  
Object mode, and as input the selected Objects (2 or more?).

- Then it's worth checking on having CSG inside of Mesh editmode too.  
This to (interactively) drill holes in stuff, etc. Could be done by  
(ab)using the current transform() code, where the selection moves  
around and intersects with the rest.

Supporting 'real' CSG in Blender is not something I see happening  
easily, this just is too far away from how hierarchies and  
relationships work in Blender now.
We also have no CSG rendering at all, which typically is done with  
tracing. My suggestion is to wait with evaluating that until we've got  
it as a modeling tool working nicely.

-Ton-



On Thursday, Sep 9, 2004, at 22:25 Europe/Amsterdam, Theodore Schundler  
wrote:

>
>
> Yes, that's basically what I meant with non destructive - doing them at
> render time (or right before). I don't think you'll get cleaner results
> that way, but if you want to use it for animation, then its necissary.
> My approach to that would be to make it an effect. I suppose the effect
> can be designed to do multiple operations on one object in a particular
> order. And (I'm not sure how doable it is) ideally the effect would  
> also
> be previewable in object mode.
> The parenting heirarchy (though I don't think it needs to be a
> heirarchy, just ObjectA U ObjectB - ObjectC type of an operation should
> work sufficiently) would be defined using that effect.
>
> As I mentioned, the boolean operation I plan to code to be used in a
> variety of places - from the GUI, from an effect, and from Python. So  
> if
> one wants to use it, to create some sort of CSG heirarchy operation,
> that should be no problem.
>
> As for doing it on the pixel level, I don't know that its very
> practical. You could produce perfect results with s-meshes and such by
> doing all operations treating them as actual curves, and not mesh
> approximations of curves. However, that only works for raytracing.
> What blender does is render faces (quads & tris) into a zbuffer first.
> and it doesn't do it by tracing rays from the camera to a face. It does
> a view transformation on the vertex set, and it just renders the faces
> using their X & Y coordinates after the transformation, and using the Z
> coordinate of the face to fill it in the zbuffer. Then it figures out
> what to shade based on what is in the resulting scene. (sorry if that
> isn't exactly right, I haven't really poked around with the render  
> pipe)
> So everything must be converted to a mesh first. Even blender's
> raytracer does its first pass this way. I suppose the quad & tri
> rendering could be made smarter, but it would be at a significant  
> impact
> on speed. If the better results are necissary, then you can smooth
> subdivide the mesh a bit. (if I get smooth intersection calculation
> working, then you may not even need for any extra subdividing the mesh
> to get a nice & smooth result)
>
>
> Ted
>
>
>>>> DanielPGB_Vasquez at hotmail.com 09/09/04 7:27 AM >>>
> Hello Robert and the ML!
>
> Let me jump in this discussion for one quick additional note:
> There was a quick discussion about booleans on the .org board some
> months ago:
> http://www.blender.org/ 
> modules.php?op=modload&name=phpBB2&file=viewtopic&t=3422&highlight=bool 
> ean
>
> The major point about the discussion was finally to point out that I
> had come across some software that handled booleans on rendertime.
> Shade can do both: rendertime bools and clean definitive (magic?)
> on-mesh bools. (they work for polygons too)
>
> This can complete(/compete with) what some call "instanced-booleans"
> where the software does the bool operations on-the-fly using instanced
> copies of the intersecting objects. This means you move the original
> objects (which can get ghosted to clean up the view) and the boolean
> result updates... hum... this might be what Theodore Schundler means
> by "non-destructive" booleans.
>
> Ciao and continue the good work coders!!
> Dani
>
>
>
>> Has anyone discussed the possibility of making the Boolean code
> capable of
>> handling real CSG trees?  IE; add a CSG Object, inside the CSG, add
> a
>> sphere and an overlapping cyl.  Parent the cyl. to the sphere,
> select
>> "subtract", and you have a sphere with a round hole.
>>
>> Later, you can replace the cyl. with a cube, and you now have a
> sphere with
>> a square hole... Or change the operation to "interfere" and you have
> a
>> cyl./cube with rounded ends...   Or edit the cyl. and have the hole
> change
>> shape... etc...
>>
>> The trees (ideally) can have an arbitrary number of levels, ie; the
> cyl.
>> could have children that affect it's shape prior to it operating on
> the sphere.
>>
>> Even if you are not going to code CSG's, try to keep this
> possibility
>> open/easy for the future while working on your new boolean code...
>>
>> Robert Wenzlaff
>> (aka Detective Thorn)
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
> This message scanned for viruses and SPAM by GWGuardian at SCU (MGW1)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org