Here's some images from my blob2 patch:

2 sphere-capped cylinders and 2 hard-edged cylinders:
http://home.earthlink.net/~cjameshuff/temp/blob2.png

A sphere and 3 torus components:
http://home.earthlink.net/~cjameshuff/temp/blob2_2.png

And here's some comparisons with the blob primitive. A 4-sphere 
tetrahedron, using the same blob components for both:
http://home.earthlink.net/~cjameshuff/temp/tetrablob.png

And the blob tweaked to be as similar to the blob2 as possible:
http://home.earthlink.net/~cjameshuff/temp/tetrablob2.png

Render speeds are slightly slower than a blob where a direct comparison 
is possible, but optimization is far from complete. You will sometimes 
get artifacts similar to those from an isosurface, the blob2 solving 
method is very similar to that used by the isosurface primitive.

Component textures are not implemented yet, that will have to wait for a 
later version of the patch. Currently implemented primitives are sphere, 
sphere-capped and hard-edged cylinder, hard-edged cone (the sphere 
capped cone exists but is buggy), torus, and box.

I'll be releasing the source code as part of my revived MegaPOVPlus 
collection...sometime soon.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote in news:cjameshuff-
5B7### [at] netplexaussieorg:

> And the blob tweaked to be as similar to the blob2 as possible:
> http://home.earthlink.net/~cjameshuff/temp/tetrablob2.png
> 
> 

That's peculiar. With such a subtle change in the density curve for 
components, I wonder why there's such a massive difference in the resulting 
shape. I can deal with the discontinuities in the second derivative thing 
for blob1, but it seems like the numbers just add up differently somehow. 

maybe subtle is just enough for such a change. eh oh well.

Post a reply to this message

On Sat, 05 Jul 2003 15:49:11 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> Here's some images from my blob2 patch:

Interesting.

> You will sometimes 
> get artifacts similar to those from an isosurface, the blob2 solving 
> method is very similar to that used by the isosurface primitive.

Have you tried to make the same blob2 via SDL as isosurface and compared
results/speed? Is that possible at all?

ABX

Post a reply to this message

In article <3l3igvkndgn43fn0s873ac5n040bnh3a6h@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Have you tried to make the same blob2 via SDL as isosurface and compared
> results/speed? Is that possible at all?

It is possible, my original tests used isosurfaces and user-defined 
functions. I haven't bothered to compare the speed before now because 
the blob2 is so obviously faster. There are several optimizations that 
are not possible with isosurfaces. For example, the algorithm collects 
the components that are hit by the ray and usess that list during the 
intersection search, while an isosurface must add every component 
together for every evaluation.

Here's some timings:
tetrablob, blob: 3 seconds (4 with sturm)
tetrablob, blob2: 4 seconds
tetrablob, isosurface: 27 seconds

(Note: the isosurface seems to get some odd surface and edge blemishes 
that I'm not seeing with blob2, I might be doing something with my patch 
that could also be useful for isosurfaces.)

These tests aren't very good for comparing blob and blob2, but more 
complex blobs become impractical to implement as isosurfaces. A blob 
with 500 sphere components in a spherical cluster renders with the blob 
primitive in 7 seconds, with the blob2 primitive in 16 seconds. It's a 
little early to make this comparison though...I haven't implemented all 
the possible optimizations for the blob2 shape.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Mon, 07 Jul 2003 11:52:43 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> These tests aren't very good for comparing blob and blob2, but more 
> complex blobs become impractical to implement as isosurfaces.

Using modularization and helpers like in IsoCSG library you can do things never
easy expected like
http://news.povray.org/povray.binaries.animations/32078/227007/isotorspline.mpg.
In your case see at
http://www-public.tu-bs.de:8080/~y0013390/pov/ic/docu02.html#Blob_Array that
even complex bloba can be made
http://www-public.tu-bs.de:8080/~y0013390/pov/ic/sample10.jpg
http://www-public.tu-bs.de:8080/~y0013390/pov/ic/sample07.jpg
as isosurface. Of course it is not spead deamon but who care about speed here
;-)

ABX

Post a reply to this message

In article <irajgvotp3bddgjdmvmmj1eee11q8pr083@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Using modularization and helpers like in IsoCSG library you can do things 
> never easy expected like

I didn't say impossible, I said impractical. Slow (which gets much worse 
with larger and more complex blobs), and it has a very awkward syntax 
even when using helper macros. And you may still run into the 
limitations of the function VM.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Was I wrong in thinking there were people interested in this?

It's odd, there've been other threads about improving the blob object, 
exponential blobs, etc. But now that there's an actual working patch 
fixing several of these problems, there's not even a hint of interest?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Thu, 17 Jul 2003 18:51:40 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> It's odd, there've been other threads about improving the blob object, 
> exponential blobs, etc. But now that there's an actual working patch 
> fixing several of these problems, there's not even a hint of interest?

Always look on the bright side of life. Your patch is first unofficial patch
announced on main www.povray.org page, even so your description says it is
kind of work-in-progress and there were more 'important' patches relased
earlier. :-)

ABX

Post a reply to this message

Christopher James Huff wrote:
> 
> Was I wrong in thinking there were people interested in this?
> 
> It's odd, there've been other threads about improving the blob object,
> exponential blobs, etc. But now that there's an actual working patch
> fixing several of these problems, there's not even a hint of interest?

Well, i think there is quite some interest but there are also problems
that might not seem that obvious to you:

1) Good documentation is the key to successful patches.  This especially
applies for end user documentation but also to source comments.  I had a
look at the source and have to say i don't really understand much.  I
would strongly suggest you at least write something about the used
techniques, especially how it differs from the isosurface intersection
method.  I for example don't really understand why this patch is a
separate object and not a special function for using in isosurfaces (which
would have a lot of advantages for the user).

2) Most patches that became popular in the past were in a more or less
'finished' state.  This does not mean they were perfect but bugs and
insufficiencies were manageable.  I know this patch is still quite new but
you have the tendency to leave patches unfinished (i would for example
have loved to include your 'g' function patch in MegaPOV 1.0).  I have not
tested this blob2 in detail but you write that there are quite some things
that need work.

3) A compiled version for the most important platforms is very important. 
As i have previously said you are very welcome to offer your patches for
inclusion in MegaPOV.  Of course there is no new version at the moment
(you know why) so i understand you are releasing it separately.  Of course
this is also related to the other points - for inclusion in MegaPOV some
work on the documentation would be required at least.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3F17B9EE.C33CC1F4@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> 1) Good documentation is the key to successful patches.  This especially
> applies for end user documentation but also to source comments.  I had a
> look at the source and have to say i don't really understand much.  I
> would strongly suggest you at least write something about the used
> techniques, especially how it differs from the isosurface intersection
> method. 

Usually I get a question if the user documentation is unclear. This 
patch is quite similar to existing features, and there's a scene file 
that shows off most of the features.


> I for example don't really understand why this patch is a
> separate object and not a special function for using in isosurfaces (which
> would have a lot of advantages for the user).

I abandoned that approach early on. An isosurface function would make 
many of the optimizations used impossible, make a manually specified 
container object mandatory, etc. Other than those blob2-specific 
optimizations, it probably works very similarly to the isosurface method 
without the evaluate option.


> 2) Most patches that became popular in the past were in a more or less
> 'finished' state.  This does not mean they were perfect but bugs and
> insufficiencies were manageable.  I know this patch is still quite new but
> you have the tendency to leave patches unfinished (i would for example
> have loved to include your 'g' function patch in MegaPOV 1.0).  I have not
> tested this blob2 in detail but you write that there are quite some things
> that need work.

Sphere capped cylinders don't work right, and I haven't really tested 
the box primitive much. It isn't completely optimized yet. Other than 
the multiple textures feature, it is as more functional than the blob 
primitive: sphere and sphere-capped cylinders work fine, as well as 
torus and hard-edged cylinders and cones. I haven't had any crashing 
problems with it.

As for "G": I kind of got stuck figuring out how to have the language in 
the same file as the scene, so it was forced into separate files...which 
was inconvenient. I decided to extend the language a bit more and turned 
it into Amber. I haven't done much work on it, but I haven't abandoned 
it.


> 3) A compiled version for the most important platforms is very important. 
> As i have previously said you are very welcome to offer your patches for
> inclusion in MegaPOV.  Of course there is no new version at the moment
> (you know why) so i understand you are releasing it separately.  Of course
> this is also related to the other points - for inclusion in MegaPOV some
> work on the documentation would be required at least.

I can not do a Windows version or a GUI Mac version. The source code 
should compile on any Linux or Mac OS X machine, it is no harder than 
installing a binary.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message