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