 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3980AFE1.CA635727@videotron.ca>, pk <thi### [at] videotron ca>
wrote:
Well, I guess you have already gotten enough information on Vahur
Krouverk's shader patch...
> Do you guys think we could sort of extend the particule systems to use
> real objects defined in pov's syntax
What exactly do you mean?
If you are talking about my particle_system patch, you *can* use any POV
object with it. You could even have the camera follow a particle.
> (or maybe somthing like the lights: a big particule that more or less
> looks like the real object, and the object to draw on top of the
> position?)
Now this is really confusing...nothing like that is done anywhere in
POV...or do you mean something like the looks_like keyword, which places
an object at the position of the light_source?
My original patch had something like that(custom_particle), but it was
replaced with a get_particle function which is much more versatile. It
just gives you the particle information, and allows you to do anything
you want with it.
> This would be interesting to help animations, and also would be better
> if you could add some predefined behaviors(like, follow sokine at start,
> and only then start using the animation system)
Are you talking about some kind of kinetics simulation system? So, for
example, you could drop a pair of boxes on a plane and have them bounce
to a resting position, like a pair of dice? And maybe have linked
structures with inverse kinematics calculation?
It might be possible to add this sort of thing, maybe as a
kinetic_system object which could hold particle_systems, cloths,
strings, gels, and solid objects. The biggest problem, one which I have
run into with my particle_system patch, is describing motion. I may have
to resort to splines, but I would rather figure out some way of
re-parsing an ordinary transformation which uses the clock value, like
everything else in POV.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk wrote:
> Displacement shaders would be nice, but seems like only viable solution
> is tesselation of surfaces into micropolygons in order to displace them.
> And implementation of this for each object type will require much of
> changes. Easiest would be to add displacement shader support to already
> tesselated objects (and triangle meshes).
Until recently (well, some months ago...), BMRT didn't have support
for displacement mapping, so don't worry. I think that what you're
currently doing is a very interesting experiment, and that the goal
isn't to become totally RM compatible. Being able to use custom
texture algorithms will be a significant leap, and will quickly bring
very useful things, as textures' self-antialiasing, for example...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, i guess i wasn't very clear 8)
Yes, i was talking about a kinetic system, but one that would also let
you define the movement yourself(so you could move an object in a
completely impossible way)
And, yes i was talking about the looks_like keyword...
No, i don't think that it would be posible as macros, and a patch would
be completely out of context in POV, i think, so a front-end would be
good, i think.
One of the problems would be parsing the objects, and knowing what each
object looks like; we'd probably have to give place to meshes to
approximate the objects, and even USE meshes if the objects get
deformed...
The information needed(that i see for the moment) would be:
Mass
Elasticity
Object definition
Speed in a vector(x,y,z)
Start position
We could implement it with the clock and an array, but you'd lose the
ability to see objects deform when they bounce, etc, and cloth would
be... hard, to say the least 8)
So, we could:
1. emit a file for each frame(yuck, but if it's needed...)
2. emit include files for each frame, and then use arrays to choose
which one to include(or which part of the include file to use)
I think that it'd be very hard to just do this with a text based
approach, so there should be a GUI... Damn: portability... or maybe use
a text based approach, like POV does with bezier patches, blobs, etc,
even though it'd be hard to do by hand, and just make GUIs for each
platform...
PS. Good luck with your patch, Mr. Krouverk!
[snip]
(for POV's server storage space's)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This would be an extremely valuable addition to POV-Ray - please persevere in this
project - absolutely everyone will thank you.
PS Do you know of any tutorials on using the shader language.
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pabs wrote:
>
> This would be an extremely valuable addition to POV-Ray - please persevere in this
> project - absolutely everyone will thank you.
> PS Do you know of any tutorials on using the shader language.
Try these:
Shader environment description:
http://www.pixar.com/products/rendermandocs/toolkit/RISpec/section12.html
General link to RM 3.1 (relevant part is shading language):
http://www.pixar.com/products/rendermandocs/toolkit/RISpec/index.html
RM 3.8 SL extensions:
http://www.pixar.com/products/rendermandocs/toolkit/Toolkit/slextensions.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
>
> Until recently (well, some months ago...), BMRT didn't have support
> for displacement mapping, so don't worry.
I would say, that this is more some years ago, as L. Gritz mentions it
in his paper from year '96. Are you sure that you don't confuse it with
DSO support, which was added recently?
> I think that what you're
> currently doing is a very interesting experiment, and that the goal
> isn't to become totally RM compatible. Being able to use custom
> texture algorithms will be a significant leap, and will quickly bring
> very useful things, as textures' self-antialiasing, for example...
>
Aliasing has to wait a little bit, for as I said, first release will not
support differential part: my math is rusty and I thoght that I will
release first version without it, so other can play with it while I add
support for differentials (or figure this math out). So long one can use
brute-force method: POV-Ray antialiasing.
> Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 31 Jul 2000 09:38:05 +0200, Vahur Krouverk wrote:
>Aliasing has to wait a little bit, for as I said, first release will not
>support differential part: my math is rusty and I thoght that I will
>release first version without it, so other can play with it while I add
>support for differentials (or figure this math out). So long one can use
>brute-force method: POV-Ray antialiasing.
Look up the '99 SIGGRAPH paper on tracing ray differentials. The only hard
part appears to be finding shape functions for arbitrary surfaces.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> Look up the '99 SIGGRAPH paper on tracing ray differentials. The only hard
> part appears to be finding shape functions for arbitrary surfaces.
I have this paper, as you mentioned it in "Square and triangular
pattern" thread in this ng, from what it all started. I've collected
some other papers as well (one of them describes finding of curvature
for implicit surfaces ("illumination from curved reflectors", from
SIGGRAPH '92 papers) as well as l. Gritz' paper of global illumination,
where BMRT implementation is discussed) so I feel myself armed more or
less. But I consider this quite complex task still and think that its
implementation would require considerable time (at least from me).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39836C87.33958858@videotron.ca>, pk <thi### [at] videotronca>
wrote:
> No, i don't think that it would be posible as macros, and a patch would
> be completely out of context in POV, i think, so a front-end would be
> good, i think.
It would be possible with macros, it would just get unbearably slow. And
I think it would work just fine as a POV patch...a front end wouldn't be
any more necessary than it is for the particle_system patch.
I would do it as a superset of the particle system, which could hold
particles, cloths, strings, gels, and solids.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <398C643F.8A35D43D@sk.sympatico.ca>, Bruce L
<dke### [at] sksympaticoca> wrote:
> Would it be possible to (mis)use the color_map structure? Instead of a
> color component, they would contain a rotation, scale or translation
> vector. I've been looking at something similar for my parameterized
> people includes, but it gets pretty sloppy pretty fast when you need to
> start concatenating several transformations.
It would be possible, but would require a completely different(and more
memory consuming, and slower) way of storing the transformation, and
would be more limiting.(you would be limited to a certain sequence of
transforms, you could only change their parameters)
It would also be difficult to use.
> On the other hand, having a transformation_map{} structure may provide
> beneficial for just this type of thing, and perhaps the existing
> interpolation code/routines used for color_map/etc could be used as a
> starting point.
Some kind of list to interpolate between transforms would be nice, but I
don't have any idea how to do it...just do an interpolation between the
matrix values? Cubic interpolation, or just linear?
What I am thinking of is a way to store the expression, so you can
replace a value(like clock) and reparse it when you need the
transformations at a specific point in time. This might be too slow, and
I haven't figured out how to save a chunk of code to repeatedly parse
later. The closest I can come is something like motion blur, where a
chunk of code is repeatedly parsed as soon as it is encountered.(I used
this method for custom_particle before I got too frusterated with it's
limitations and replaced it with get_particle functions) Of course, I
could just do this and store the transforms...but when you have 100's of
iterations, the amount of memory devoted to storing matrices gets
unacceptable.(16 doubles per matrix, two matrices per transform, one
transform per iteration...)
It might end up being the only/best way, but I would rather use a more
memory-efficient method.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
