 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] videotron ca>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39905AF9.28ABD3CB@sk.sympatico.ca>, Bruce L
<dke### [at] sksympaticoca> wrote:
> The infamous quaternions? Have to admit I'm not up on them that much
> myself, but they seem to work well with the rotation aspects. How well
> they can (could) be applied to handling scaling/translation would
> require advice from some one with more expertice. There is a fair amount
> of code laying around though.
I don't really know anything about quaternions...but everything I have
seen about them seems to be about storing and calculating rotations, so
they probably wouldn't be very useful. And they would have the same
problems with animating...
> I don't know enough about the internal workings to comment, other than
> to say you could dump out a source fragment and then reparse it with an
> #include. From my understanding though, this can already be done within
> plain old POV anyways, so guessing it's just to slow?
I don't know how slow it would be. Just parsing a single transform
shouldn't be too bad, and it should be more memory efficient than
storing hundreds or thousands of matrices in an array.
> Back to the spline idea <g> They're just too slow? There's code all over
> POV for several different implementations. They're fairly memory
> efficient as long as you don't have to pre-compute to much. If you use
> something like a Catmull/Rom/Clark basis, you can compute only
> those/that single value needed for the current time.
The problem with splines isn't the memory efficiency or the speed, it is
the versatility and consistency with the other POV-Ray syntax. You would
have to go back to storing a spline+transform pair for every
translation, rotation, or scaling done(and matrices would require more
than one spline). And it wouldn't make sense for animating objects in
one area to use a different syntax everywhere else.
However, if I figure out how to interpolate transforms, it is something
that could be applied to the whole POV language.
> One possible advantage to using splines would be that you could
> re-interpret what the control points actually ment. Instead of them
> being <x,y,z> they could mean <acceleration,inertia,friction>. Or
> perhaps a varying gravity directional vector for creating gravity wells
> <g>
...snip...
You are no longer specifying a transformation, you are specifying
parameters for a physics engine...you should keep "transform" for actual
transformations. Heading, speed, gravity, etc. are not transforms.
Rotate, translate, scale, matrix, axis_rotate(which I am considering
adding) are transformations.
BTW, I am using splines for a similar purpose in my particle patch, and
will be using them in the physics patch, assuming I ever get it started.
The syntax is completely different from what you have shown though. And
they will be used for settings, but not for specifying transforms, for
the above reasons.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
