 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <Chr### [at] compuserve com> wrote:
: Another thing I think would be a good idea is a built in particle
: system, which would simulate fire, smoke, water, etc. Hmm, even an
: scene_interaction keyword to make the particles respond to objects in
: the scene?
and kinematics and inverse kinematics and physics laws and...
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> Another thing I think would be a good idea is a built in particle
> system, which would simulate fire, smoke, water, etc. Hmm, even an
> scene_interaction keyword to make the particles respond to objects in
> the scene?
Well, fire's possible now. I've got a nice campfire scene using some
simple media and isosurfaces (via the Superpatch).
Lummox JR
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, but I think a particle system would be more realistic, at least for
animations. I have been writing a pretty nice particle system, but it is
in C++. Maybe I will add it when POV-Ray is converted to C++.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
An interesting idea, and possible to implement of course!
But what are the advantages and disadvantages of implementing
L-parsing as a macro vs POV native primitive? Would we want
to encourage one approach to L-Parsing as decided by the POV
team?
--
Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Primitive Pros:
MUCH faster parsing
would probably take less memory
would be easier to use the object parameters
could be made much more powerful
would have the standard object syntax
Macro Pros:
easily updated
people without a compiler could modify it
hmm, that is all I could think of.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> Primitive Pros:
> MUCH faster parsing
> would probably take less memory
> would be easier to use the object parameters
> could be made much more powerful
> would have the standard object syntax
It's not so much the parsing speed that concerns me, as the memory
issue. Objects in POV-Ray are huge; a forest full of Lparsed trees would
be enormous, if each tree consisted of 500 objects. If each tree,
however, merely consisted of 500 transformations and pointers to
objects, and the entire forest only took up 3 or 4 physical objects (the
tree sections) plus the trees themselves, then it might just work.
Plus, the amount of memory used has some effect on the rendering speed.
But it's probably quicker to check for intersections with an internal
array of 500 object pointers and transformations than with 500 other
objects on the whole list.
Also, there is the great advantage that bounding volumes could be
applied to each branch in the same manner (hmm... best make that an
additional item in the array elements), speeding up rendering time
somewhat.
The biggest problems, I think, are these:
1.) Trying to provide parameters to the branch objects. These might be
made intentionally variable depending on their position, depth in
the structure, etc. It might actually be necessary to define a
special type of object for Lparser branches, to allow for this.
2.) Creating seamless intersections. A tree doesn't just look like a
bunch of tinkertoy cylinders strung together. Rather, it might look
more like a blob object (hmm.... an interesting idea) with some
random noise to it. Where a branch goes off from the trunk, there's
a "neck" to the branch where the trunk curves outward--and when it
does go in a new direction, the texture smoothly goes with it.
Perhaps an Lparse blob type of object would be in order?
This actually gives me an idea--it might be possible to update the blob
type to include isosurfaces as per the Superpatch. With that, functions
can be used to affect the density. That might not help with this
particular problem, but I like the idea of what it could do elsewhere.
> Macro Pros:
> easily updated
> people without a compiler could modify it
> hmm, that is all I could think of.
I think "easily updated" would apply just as easily to the primitive,
too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 28 Jun 1999 14:02:52 -0400, Lummox JR wrote:
>This actually gives me an idea--it might be possible to update the blob
>type to include isosurfaces as per the Superpatch. With that, functions
>can be used to affect the density. That might not help with this
>particular problem, but I like the idea of what it could do elsewhere.
Uh... a blob _is_ an isosurface. It's just a specialized one that
has been optimized to be faster to compute than a general isosurface.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3776DBE4.5A7D7C7E@eisa.net.au>, Nigel Stewart
<nig### [at] eisanetau> wrote:
>An interesting idea, and possible to implement of course!
>
>But what are the advantages and disadvantages of implementing
>L-parsing as a macro
I just converted an old IFS-fractal type program I wrote *many* years ago
(for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
POV. I'll try and post the macro later on. (It is on my home computer, not
my office computer.)
It implements both 'building' the fractal, and 'fading in' to the fractal
(Bernhard's method, or something?)
Makes some pretty cool shapes (especially when used with blobs) but it is
nowhere near making real trees yet.
Jerry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<jer### [at] cerebusacusdedu> <jer### [at] acusdedu> wrote:
> I just converted an old IFS-fractal type program I wrote *many* years ago
> (for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
> POV. I'll try and post the macro later on. (It is on my home computer, not
> my office computer.)
Posted in povray.binaries.scene-files under the subject "Fractal Macro".
Jerry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> Uh... a blob _is_ an isosurface. It's just a specialized one that
> has been optimized to be faster to compute than a general isosurface.
True, true.
I was thinking, though, something along the lines of both: Something
with a blob's clipping capabilities, and the ability to hold multiple
components, yet using the power of functions.
Ironically, right now I'm looking through the blob code, seeing if
there's a way to add a torus-shaped component. Imagine the
possibilities. Most of it is pretty straightforward, but at the moment
I'm a bit stuck on the math of trying to get the quartic coefficients
right for All_Blob_Intersections. I can't seem to get anything less than
an 8th order equation to work mathematically, even though a 4th order
equation ought to do the trick. I'll keep at it, of course.... :)
Lummox JR
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
