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

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

> The source code should compile on any Linux or Mac OS X machine, 
> it is no harder than installing a binary.
> 


I can understand the effort required to provide binaries for multiple 
platforms... But ...please reread that statement with your user hat on.

Post a reply to this message

Christopher James Huff wrote:
> 
> > 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.

This is exactly what i meant when suggesting a better documentation.  I
still fail to see what optimizations would not be possible in a custom
isosurface function (the container is not really important if the function
is fast far away from the components due to optimization).  Descriptions
of the used techniques will be the key to understand the strength (and
possibly weak points) of the patch.

I think Tom is quite right, you seem to not enough look at it from the
user's side.  From your point of view documentation might be unnecessary
but it would be immensely important.  Try writing something under the
premise:

"In what way is the blob2 better than other solutions (existing blob shape
and isosurface blobbing solutions) and how does the patch accomplish
this."

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 <Xns### [at] 204213191226>,
 Tom Galvin <tom### [at] imporg> wrote:

> > The source code should compile on any Linux or Mac OS X machine, 
> > it is no harder than installing a binary.
> 
> I can understand the effort required to provide binaries for multiple 
> platforms... But ...please reread that statement with your user hat on.  

Maybe a clarification is needed: providing command line binaries would 
not make it any easier.

It is really true, installing from source is a matter of typing a 
slightly different command at a terminal. This is more work than 
"installing" the GUI version (which on the Mac, consists of putting the 
main folder somewhere convenient), but as I said, I can't help that. 
Making a binary distribution for the CLI version would be a fairly large 
amount of work (larger than several patches I've done), figuring out how 
to replicate the install process the makefile uses, and it would not be 
any easier.

-- 
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

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

> "In what way is the blob2 better than other solutions (existing blob shape
> and isosurface blobbing solutions) and how does the patch accomplish
> this."

Existing blob shape: the blob2 object is more flexible (having more 
component types), and uses a different falloff function that gives 
smoother blobs. Look at the pictures I've put up demonstrating the 
difference. The old blob looks like lumps covered in goo, the blob2 
looks like it's just the goo.

Isosurfaces: the main advantage is that it is faster. It uses 
optimizations that can't be done in even a hard-coded isosurface 
function. For example, it collects the components that influence a ray, 
and uses only those when searching for the intersection. If you have a 
blob2 with hundreds of components, but only two components affect the 
current intersection being tested, only those two components will get 
evaluated.

In addition to this, the blob2 uses this list to automatically figure 
out the beginning and end of the interval to check for intersections. 
Not only do you not have to specify a container, the blob2 algorithm 
comes up with more accurate bounds than you could specify anyway, using 
the bounding shapes of individual components.

It also seems to give smoother results with low accuracy. Artifacts do 
show up, but the isosurface shape gives a more visible "stepping". This 
may just be an illusion, a bug with the isosurface, or something I'm 
doing with blob2 that the isosurface doesn't. It might be an effect of 
the interval checking mentioned above, it is like having a more 
irregular container.

-- 
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:cja### [at] netplexaussieorg: 


> 
> It is really true, installing from source is a matter of typing a 
> slightly different command at a terminal. 


Assuming that the compile is successful, assuming that dependencies are 
local and the correct version, assuming that the user knows what a compiler 
is, assuming that a complier is even installed on the system....

Post a reply to this message

Christopher James Huff wrote:
> 
> [some more explanations]

Well, it looks like a good start.  Illustrate it with some images, some
diagrams and formulas of the falloff functions, some render times for
comparison, a syntax summary and you already have a quite helpful addition
for the user.

> Isosurfaces: the main advantage is that it is faster. It uses
> optimizations that can't be done in even a hard-coded isosurface
> function. For example, it collects the components that influence a ray,
> and uses only those when searching for the intersection. If you have a
> blob2 with hundreds of components, but only two components affect the
> current intersection being tested, only those two components will get
> evaluated.

Well, in functions you could do the same on a point basis instead of ray
basis and add some caching if the next point is near the old one.  Surely
it will be slower but as i said having it in isosurfaces would also have
some serious advantages.

Note that handcoded isosurface functions for blobbing or CSGing many
components scale extremely badly, even if an internal function for this
would not be as fast as your new shape it would be ways faster than the
manual approach.

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 <Xns### [at] 204213191226>,
 Tom Galvin <tom### [at] imporg> wrote:

> > It is really true, installing from source is a matter of typing a 
> > slightly different command at a terminal. 
> 
> Assuming that the compile is successful, assuming that dependencies are 
> local and the correct version, assuming that the user knows what a compiler 
> is, assuming that a complier is even installed on the system....

If someone can install the official command line version (which is 
needed anyway before doing this), the dependencies are already taken 
care of. A binary install would involve more time and work for 
assembling and testing, and for very little benefit, especially 
considering the level of interest I'm seeing.

-- 
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

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

> Well, it looks like a good start.  Illustrate it with some images, some
> diagrams and formulas of the falloff functions, some render times for
> comparison, a syntax summary and you already have a quite helpful addition
> for the user.

Demanding, aren't we?
Considering the lack of interest I'm seeing in this, I'm putting this 
patch on the backburner, there won't be another MP+ release until I have 
more patches moved over. When that happens, there will be documentation 
of the syntax and some more sample scenes, and the documentation of the 
source code will be improved. In the meantime, I have other projects I 
need to attend to first.


> Well, in functions you could do the same on a point basis instead of ray
> basis and add some caching if the next point is near the old one.  Surely
> it will be slower but as i said having it in isosurfaces would also have
> some serious advantages.

Caching is useless here...at least, I see no way of applying it that 
doesn't just add overhead. And without ray info, you can't do the same 
thing. The point of doing it on a per-ray basis is that you can take a 
fairly expensive computation (the bounds test/component collection 
stage) and use it to optimize a large number of expensive computations 
(all the point evaluations needed to find the intersections with the 
ray) that would otherwise be many times the first calculation. Drop that 
and you're back to looking at every single component for every point 
evaluated. You could still derive some benefit from a heirarchial 
bounding scheme, but so could the existing algorithm.

There will be a blob2 pattern. This will not be able to use these 
optimizations either, but like any other pattern, you will be able to 
use it in isosurfaces. But I have good reasons for not doing it this way 
for the blob2 primitive.


> Note that handcoded isosurface functions for blobbing or CSGing many
> components scale extremely badly, even if an internal function for this
> would not be as fast as your new shape it would be ways faster than the
> manual approach.

By scaling, you appear to mean performance with increasing numbers of 
components...removing these optimizations would make the order of the 
algorithm equal to hand coded functions, performance would deteriorate 
linearly as number of components increases. You would only get the 
benefits of compiled functions. (plus the fact that the functions 
themselves are more optimized)

-- 
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 wrote:
> 
> > Well, it looks like a good start.  Illustrate it with some images, some
> > diagrams and formulas of the falloff functions, some render times for
> > comparison, a syntax summary and you already have a quite helpful addition
> > for the user.
> 
> Demanding, aren't we?

I'd rather say suggesting.  If you don't want to go this way i won't urge
you but you were the one who wondered about the lack of interest.

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

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


> 
> If someone can install the official command line version (which is 
> needed anyway before doing this), the dependencies are already taken 
> care of. A binary install would involve more time and work for 
> assembling and testing, and for very little benefit, especially 
> considering the level of interest I'm seeing.
> 

I used the official binary for my Redhat linux box.  I don't want you to 
make a binary for me.  I am capable of getting it running, but I don't have 
the time to play with it.  I am just giving you the user perspective.

Post a reply to this message

In article <cja### [at] netplexaussieorg>, 
cja### [at] earthlinknet says...
> Considering the lack of interest I'm seeing in this

I think it sounds interesting and more useful that the current blob 
system, but then I am one of the people that refuses to compile this sort 
of thing myself. I don't do that sort of thing often, I have had bad 
experiences with stuff that the authors claimed was 'all ready, just type 
blah... and it will work', I don't trust my system to not have dependency 
problems that being Windows I might have a snowball's chance in hell of 
fixing properly. For me, it is either a working patched version of the 
binary or nothing. I suspect others feel much the same.

I also believe that as much documentation as possible is a necessity. One 
reason I don't try to compile my own versions is that I don't know C very 
well and the POV source looks like bloody greek to me. I have neither the 
time nor the patience to wander through pages of someone else's code 
trying to figure out what the hell it does, because the designer doesn't 
document it or the use of its features completely. You may consider it a 
waste of time, but if you aim for the lowest common denominator (the 
people that haven't a single clue what is going on), then no one will be 
cursing you for it. If you instead assume that everyone that will use it 
has nearly the same knowledge you do, then even your equals will curse 
your name for not giving a better explanation of what 'you' chose to do, 
because 'they' would might have done it completely differently.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

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 was actually waiting for someone to come up with a better 
blob because each time I model some blob object, I was unhappy with 
these somewhat ugly lines caused by the linear falloff function. 

I was happy when I read that you released you patch finally but 
after seeing that I'd have to download more than 1Mb with my 
slow modem, I decided to wait for the next MegaPov version...

So really, there _are_ people who are interested in the blob2 
and if it is faster than isosurface, I'd apreciate that much because 
rendering time is an issue for animations. 

Regards,
Wolfgang

Post a reply to this message

In article <3f1db4da@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> Well, I was actually waiting for someone to come up with a better 
> blob because each time I model some blob object, I was unhappy with 
> these somewhat ugly lines caused by the linear falloff function. 

This seems to be a common misconception...the blob falloff function is 
not linear. The function given in the documentation is:

strength*(1 - (distance/radius)^2)^2

The problem is that it has non-0 second derivative when distance/radius 
equals 0, which is at the very edges of the blob components where the 
function gets chopped off. Because of this, while the surface is 
continuous, it has abrupt changes in curvature. The function I used for 
the blob2 object is:

((6*r - 15)*r + 10)*r*r*r

which is equivalent to:

6*r^5 - 15*r^4 + 10*r^3

with r = distance/radius in the first equation. It has a second 
derivative which is 0 at r = 1, and seems to give a more fluid, less 
chunky looking shape as well. This function actually comes from a recent 
update to the Perlin noise algorithm which fixed a similar problem that 
resulted in grid artifacts.

-- 
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 wrote:

> Considering the lack of interest I'm seeing in this,

If you want to raise interest, SHOW PICTURES to the public, in pbi.

Within a few days, many people will show interest, and as soon as
someone decides to compile a Windows (the most widely used platform
for POV-Ray, simply) binary, these many people will actually
be USING the patch.

Fabien.

Post a reply to this message

In article <3f1df3cc@news.povray.org>,
 Fabien Mosen <fab### [at] skynetbe> wrote:

> > Considering the lack of interest I'm seeing in this,
> 
> If you want to raise interest, SHOW PICTURES to the public, in pbi.

I did put pictures up, and gave links in my original message. Uploading 
anything substantial is a pain on this connection...I don't even read 
povray.binaries.images regularly. Again, here are the pictures:

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

-- 
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 wrote:

> > If you want to raise interest, SHOW PICTURES to the public, in pbi.
> 
> I did put pictures up, and gave links in my original message. Uploading
> anything substantial is a pain on this connection...I don't even read
> povray.binaries.images regularly. Again, here are the pictures:

From a software engineering perspective, your images are technically
suffecient to portray the function of your patch but from a purely
artistic point of view they lack the "shock and awe" valued needed
to sell it. A little artistic creativity will go a long way...

-- 
Ken Tyler

Post a reply to this message

Christopher James Huff wrote:
> In article <3f1df3cc@news.povray.org>,
>  Fabien Mosen <fab### [at] skynetbe> wrote:
> 
> 
>>>Considering the lack of interest I'm seeing in this,
>>
>>If you want to raise interest, SHOW PICTURES to the public, in pbi.
> 
> 
> I did put pictures up, and gave links in my original message.

OK, sorry, I've read the announcement on POV-Ray's homepage,
which doesn't give the links.

Do you want/allow me to post these images in pbi ?

Fabien.

Post a reply to this message

In article <3f1e1e7a$1@news.povray.org>,
 Fabien Mosen <fab### [at] skynetbe> wrote:

> OK, sorry, I've read the announcement on POV-Ray's homepage,
> which doesn't give the links.

Hmm, I guess I should have written a separate, more complete 
announcement for that...


> Do you want/allow me to post these images in pbi ?

If you want...as Ken mentioned, they aren't much, just showing some of 
the differences from the original blob 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

In article <3F1### [at] pacbellnet>, Ken <tyl### [at] pacbellnet> 
wrote:

> From a software engineering perspective, your images are technically
> suffecient to portray the function of your patch but from a purely
> artistic point of view they lack the "shock and awe" valued needed
> to sell it. A little artistic creativity will go a long way...

Heh...well, they were created either to test components or to compare 
blob and blob2. I've actually never done anything artistic with blobs. 
(Aside from an early version of isocacti.pov which used blobs for rocks)

I'll try to come up with some better demo scenes for the next release.

-- 
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 wrote:
> The problem is that it has non-0 second derivative when distance/radius
> equals 0, which is at the very edges of the blob components where the
> function gets chopped off. Because of this, while the surface is
> continuous, it has abrupt changes in curvature. 
>
That's what I mean -- these "abrupt changes in curvature" when looking 
at the blobs. It needs to get fixed. 

> 6*r^5 - 15*r^4 + 10*r^3
> 
> with r = distance/radius in the first equation. It has a second
> derivative which is 0 at r = 1, and seems to give a more fluid, less
> chunky looking shape as well. 
>
I see. Thanks for pointing that out. 

Wolfgang

Post a reply to this message

Christopher James Huff wrote:
> . . . . The function I used for the blob2 object is:
> 
> ((6*r - 15)*r + 10)*r*r*r

Why quintic?  All we absolutely need is

	f(0) = 1
	f(1) = f'(1) = f''(1) = 0

for which (1-r)^3 would do; were you also trying to fit the traditional 
curve?

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

In article <3f84f22f$1@news.povray.org>, Anton Sherwood <new### [at] ogrenu> 
wrote:

> > ((6*r - 15)*r + 10)*r*r*r
> 
> Why quintic? 

This function is used in several other places as well, such as the 
recent updates to Perlin noise. It's not something I came up with.


> All we absolutely need is
> 	f(0) = 1
> 	f(1) = f'(1) = f''(1) = 0

No, you also need f'(0) = f"(0) = 0


> for which (1-r)^3 would do; were you also trying to fit the traditional 
> curve?

(1-r)^3 doesn't even remotely resemble the old-style curve. I wasn't 
trying to "fit" it, but I did want something that was somewhat similar.

-- 
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 wrote:
> Anton Sherwood <new### [at] ogrenu> wrote:

>>> ((6*r - 15)*r + 10)*r*r*r
>>
>> Why quintic? 
> 
> This function is used in several other places as well, such as the 
> recent updates to Perlin noise. It's not something I came up with.

Ah.
I imagine that would have more constraints.


>> All we absolutely need is
>>	f(0) = 1
>>	f(1) = f'(1) = f''(1) = 0
> 
> No, you also need f'(0) = f"(0) = 0

Why?  That point is never on the surface (unless, I guess, another 
component with greater and opposite strength is in just the right place).

And shouldn't f''(0) be negative rather than zero?

We also want f'(t)<0 for 0<t<1, but that's almost automatic with a 
polynomial of low degree that fits the other constraints.  ;)


 >> for which (1-r)^3 would do; were you also trying to fit
 >> the traditional curve?
 >
 > (1-r)^3 doesn't even remotely resemble the old-style curve. I wasn't
 > trying to "fit" it, but I did want something that was somewhat similar.

(1-rr)^3, then, and you get f'(0)=0 for free.  ;)


...It occurs to me that my remarks may seem hostile in tone.
Please be assured that it is none of my intent.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

In article <3f863fc0@news.povray.org>, Anton Sherwood <new### [at] ogrenu> 
wrote:

>  > (1-r)^3 doesn't even remotely resemble the old-style curve. I wasn't
>  > trying to "fit" it, but I did want something that was somewhat similar.
> 
> (1-rr)^3, then, and you get f'(0)=0 for free.  ;)

You may be right, I will have to do more tests when I have time. I do 
like the shape given by the quintic curve.

-- 
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