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 () {

    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