|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
nonlinearly. Or they could if there was functions in POV-ray that was
designed to do this...
I suggest that we begin to think of the possibilities of implementing such
functions. I personally believe that it could improve POV-Ray significantly
in some of the areas where it is currently not as powerful as many other
renderers.
To make such functions useable it would probably be necessary to implement
several different kinds of those nonlinearly transformations. They could all
be contained into a statement such as deform {} or something.
One type of deform could be one that deforms dependent on warps:
deform {
warp {...}
}
As you can sure imagine, this alone would be a very powerful and general way
of deforming the supported object.
But more complicated ways of deforming may be useful. I have thought of a
feature that would deform objects by several user-specified regular
transforms, each weighted by a 3D field in space. I believe this could be
used for many things. For example it could be used to make a kind of bone
structure. One part of a mesh body could be enclosed by one field which
would be transformed by one linear transform. Another part of the body would
by due to another field be transformed by another linear transform. The
3D-fields could be defined by patterns, which would be very flexible, but
probably also rather difficult to master and somewhat slow, or they could be
controlled in a way similar to blobs, which would be less flexible, but
surely easier to understand, and probably faster. Possible syntax:
deform {
field_transform {
sphere {
location, radius, strength,
transformations (of the field)
apply_transform transform_id (of the mother object, such as mesh)
}
cylinder { (like sphere, but with end1, end2 instead of location) }
...
}
}
alternative way:
deform {
field_transform {
field {pattern_id, transform_id}
field {pattern_id, transform_id}
...
}
}
The pattern way of field_deform could be used with blob_pattern to achieve
same functionality I guess, but it would probably still be slower.
Other deform types could possible be made too. What do you think of the
whole idea?
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...
Iso-surfaces can be transformed non-linearly by adding transformation
functions within the iso-surface itself. (I just posted an example in
povray.binaries.images)
But this is very painful !
So other methods to torture them would be very welcome.
Regards,
Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a5a3a2d@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...
You can apply non-linear transformations to isosurfaces by modifying
their functions. Bicubic patches, height fields, meshes, and other
tesselated objects could also be deformed fairly easily without changing
the rendering method very much, but you would have to make fairly major
additions to the code.(I once made an attempt at deformable meshes, but
failed completely)
> I suggest that we begin to think of the possibilities of implementing
> such functions. I personally believe that it could improve POV-Ray
> significantly in some of the areas where it is currently not as
> powerful as many other renderers.
You're a little late...Wlodzimierz ABX Skiba has already been working on
a deform patch, which apparently can work on all objects. Also, Warp is
working on a tesselation patch that could be used to do similar things.
All of this was discussed, including the possibility of using warps.
Look around in povray.unofficial.patches, it was fairly recent.
> But more complicated ways of deforming may be useful. I have thought of a
> feature that would deform objects by several user-specified regular
> transforms, each weighted by a 3D field in space.
...snip...
I think it would be better to define deformations with a warp, and
implement a new warp that does this. I think it would be a good idea to
keep a single syntax for deforming both objects and textures.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
> > I suggest that we begin to think of the possibilities of implementing
> > such functions. I personally believe that it could improve POV-Ray
> > significantly in some of the areas where it is currently not as
> > powerful as many other renderers.
>
> You're a little late...Wlodzimierz ABX Skiba
simpler is write just ABX :-)
> has already been working on
> a deform patch, which apparently can work on all objects
I have changed my previous syntax for simpler usage I think
instead next object in pov syntax I have putted deform into object modifiers
in example :
ttf {
"arial.ttf" , "Hello world" 0, 1
texture { ... }
transform { translate rotate etc.. }
deform { TYPE PARAMS }
:
:
}
also declaration of deforms will be available just like declaration of
transformations, textures or other things
#declare BestTwist = deform { twist .5 }
object {
MyBox
texture { MyTexture }
deform { BestTwist }
}
Every deformation will be defined as something like pattern in pigments : twist,
envelope, curve, stretch etc followed parameters. I plan implement functions as
type of deformations after 3.5 release (I wait for specification of functions) -
deform{function{...}}
Rune's proposition of control points could be possible as part of this stuff but
... I thought about deformation depends of distance point to the bezier patch or
sth
current state of deform patch : geometry works fine, now I play with deformation
of atributes of textures applied to object
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> You can apply non-linear transformations to isosurfaces by
> modifying their functions.
Deforming functions due to simple mathematical functions can be fine. But
the kinds of transformations I'm talking about are things like for example
animating a character. This can hardly be done by having the user modifying
functions.
> Bicubic patches, height fields, meshes, and other tesselated
> objects could also be deformed fairly easily without
> changing the rendering method very much, but you would have
> to make fairly major additions to the code.
But if it would be as powerful as I wish for, it would be a fairly major
feature.
So far character animation in POV-Ray has always been using robots, or if
organic objects were used, they were not UV-mapped, and if they were, they
were animated in another program and then exported to POV-Ray. I would like
to animate organic, UV-mapped characters in POV-Ray itself. The deformation
features I'm talking about would be an important part of making that
possible.
But is it worth it making such big changes to POV-Ray just to be able to
animate characters? I think yes. I believe good character animation is
considered the highest achievement in the 3d graphics industry. And besides,
the deformations I'm talking about would be useful for *many* other things
too.
> > I suggest that we begin to think of the possibilities of
> > implementing such functions.
>
> You're a little late...Wlodzimierz ABX Skiba has already
> been working on a deform patch, which apparently can work on
> all objects.
And that's great. But I believe the kind of features I
suggested hasn't been discussed.
> Also, Warp is working on a tesselation patch that could be
> used to do similar things.
Tessellation and deformation is not the same thing. Although it would indeed
make deform features even more useful.
> All of this was discussed, including the possibility of using
> warps.
Not well enough I think.
> > But more complicated ways of deforming may be useful. I have
> > thought of a feature that would deform objects by several
> > user-specified regular transforms, each weighted by a 3D
> > field in space.
> ...snip...
You snipped the most important part...
> I think it would be better to define deformations with a warp,
> and implement a new warp that does this. I think it would be
> a good idea to keep a single syntax for deforming both objects
> and textures.
Chris, that doesn't make sense. Textures and objects are entirely different
things and cannot be deformed in the same way. Allow me to explain.
AFAIK textures are deformed in a backward kind-of-way, while meshes are
deformed in a forward kind-of-way. That means that one piece of a texture
can be copied to several locations (think repeat warp). That is not possible
with meshes.
Meshes work the other way around. That means that several pieces of a mesh
can be moved to the same location (think of a mesh snake that bends and
bites its own tail). This is not possible with textures. Texture space can't
overlap itself.
Even if some texture warps can be used on objects too, they will not give
identical perpetuations on textures and meshes. But saying that *all*
deformations should work for both textures and objects is nonsense. That's
what my logic tells me anyway.
I would appreciate if you would reconsider my suggestions so we could maybe
have a more rewarding discussion about them.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a5adc40$1@news.povray.org>, "Wlodzimierz ABX Skiba"
<abx### [at] abxartpl> wrote:
> > You're a little late...Wlodzimierz ABX Skiba
>
> simpler is write just ABX :-)
I often copy-paste my own name... :-)
> I have changed my previous syntax for simpler usage I think
>
> instead next object in pov syntax I have putted deform into object
> modifiers
This does look like a better syntax. If your technique allowed warps to
be used as deformations, it would be perfect...maybe a compromise would
be a "deform" warp, but there will be a lot of duplication, since people
will want deforms that do the same things as many of the warps.
Is your technique still limited to deformations that can be "reversed"?
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a5b1acd@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> Deforming functions due to simple mathematical functions can be fine.
> But the kinds of transformations I'm talking about are things like
> for example animating a character. This can hardly be done by having
> the user modifying functions.
That would be pretty difficult... :-)
> So far character animation in POV-Ray has always been using robots,
> or if organic objects were used, they were not UV-mapped, and if they
> were, they were animated in another program and then exported to
> POV-Ray. I would like to animate organic, UV-mapped characters in
> POV-Ray itself. The deformation features I'm talking about would be
> an important part of making that possible.
> But is it worth it making such big changes to POV-Ray just to be able
> to animate characters? I think yes. I believe good character
> animation is considered the highest achievement in the 3d graphics
> industry. And besides, the deformations I'm talking about would be
> useful for *many* other things too.
I didn't say they wouldn't...
> > You're a little late...Wlodzimierz ABX Skiba has already
> > been working on a deform patch, which apparently can work on
> > all objects.
>
> And that's great. But I believe the kind of features I
> suggested hasn't been discussed.
The patch is still in a very early stage...don't expect highly complex
features from the start.
> Tessellation and deformation is not the same thing. Although it would
> indeed make deform features even more useful.
What I meant was that objects can now be tesselated into meshes, which
would be easier to deform than ordinary objects, and it might be
possible to combine the two processes.
> > All of this was discussed, including the possibility of using
> > warps.
>
> Not well enough I think.
Did you bother to read those threads?
> You snipped the most important part...
Because it was long. :-)
> Chris, that doesn't make sense. Textures and objects are entirely
> different things and cannot be deformed in the same way. Allow me to
> explain.
They are not entirely different...it depends on how you approach things.
> AFAIK textures are deformed in a backward kind-of-way, while meshes
> are deformed in a forward kind-of-way. That means that one piece of a
> texture can be copied to several locations (think repeat warp). That
> is not possible with meshes.
Not without re-tesselating the mesh or doing some pretty ugly
calculations, true...and it depends on how the deformation is
implemented. It might be possible to tesselate and deform in one step,
allowing things like the repeat warp.
> Meshes work the other way around. That means that several pieces of a
> mesh can be moved to the same location (think of a mesh snake that
> bends and bites its own tail). This is not possible with textures.
> Texture space can't overlap itself.
>
> Even if some texture warps can be used on objects too, they will not
> give identical perpetuations on textures and meshes. But saying that
> *all* deformations should work for both textures and objects is
> nonsense. That's what my logic tells me anyway.
I never said that they should all be available for both, or that they
would be identical. But for many deformations, like turbulence, black
holes, "twist", etc... it certainly makes sense to use the common syntax.
> I would appreciate if you would reconsider my suggestions so we could
> maybe have a more rewarding discussion about them.
Are you confusing me with someone else? You seem to be reacting as if I
said your suggestions weren't any good...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> Are you confusing me with someone else? You seem to be reacting
> as if I said your suggestions weren't any good...
Nah, I just overreacted a bit on "You're a little late..." and "All of this
was discussed". I like to think I'm contributing with new ideas. But maybe I
misunderstood how much of my message those comments applied to.
> > > You're a little late...Wlodzimierz ABX Skiba has already
> > > been working on a deform patch, which apparently can work on
> > > all objects.
> >
> > And that's great. But I believe the kind of features I
> > suggested hasn't been discussed.
>
> The patch is still in a very early stage...don't expect highly
> complex features from the start.
I don't. Actually I don't specifically have that patch in mind.
AFAIU the deform patch works on all objects, but can only do reversible
functions (so far). Also, the deformation will slow down for every ray
hitting the object.
What I'm thinking of is a feature that works on mesh-like objects only. The
good thing is that the deformation only has to be calculated for the
vertices (and vertice normals). That would happen in the parsing, not the
rendering, and thus I think it would be much faster. Also, more complicated
deformations could be done.
> > Tessellation and deformation is not the same thing. Although
> > it would indeed make deform features even more useful.
>
> What I meant was that objects can now be tesselated into meshes,
> which would be easier to deform than ordinary objects.
Exactly.
> All of this was discussed, including the possibility of
> using warps.
> Did you bother to read those threads?
Yes, but what I would like to discuss in *this* thread is not tessellation,
not deformation in general, not even warps in general, but some specific
types of deformations I've thought of. Those are the types I talked about in
the original message.
> > You snipped the most important part...
>
> Because it was long. :-)
Well, can we go back and talk about that specific part?
> > Textures and objects are entirely different things and cannot be
> > deformed in the same way.
>
> They are not entirely different...it depends on how you approach things.
I should make clear that I'm talking about deforming done by moving mesh
vertices. For this type of deform all warps would work "backwards" compared
to textures.
A turbulence warp would look almost the same to the untrained eye.
A black_hole warp would push things away instead of attracting them (except
when inverted).
A repeat warp would slice a mesh and then move all the slices to the same
location!
Some warps would be rather similar for meshes and textures, while others
would work entirely different.
> I never said that they should all be available for both, or
> that they would be identical. But for many deformations, like
> turbulence, black holes, "twist", etc... it certainly makes
> sense to use the common syntax.
Yes, even though they wouldn't give identical results, they'd look quite the
same for both meshes and textures.
But now, I will start a new branch of this thread where I hope my
field_deform idea can be discussed.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" wrote:
> I have thought of a feature that would deform objects by several
> user-specified regular transforms, each weighted by a 3D field
> in space.
I thought this method could work for meshes only, since it would do moving
of vertices.
The idea was that each vertice would be transformed by an average of several
regular transform matrixes. The weights of the different matrixes in a given
point would be determined by the values of their fields in that point.
I have though of two field-types: Absolute and relative.
For the absolute type, if for a given point one field had a value of 0.1 and
another field had a value of 0.3, the first field would contribute 10% of
the transformation matrix, while the other field would contribute with 30%.
The remaining 60% would be contributed by the index matrix (a matrix that
doesn't do anything).
For the relative type, if for a given point one field had a value of 0.1 and
another field had a value of 0.3, the first field would contribute 25% of
the transformation matrix, while the other field would contribute with 75%.
The index matrix would never contribute with anything.
The absolute type would be useful when you want one part of your object to
be deformed, and the rest to stay undeformed.
The relative type would be useful for things like bone systems, where every
part of the mesh is deformed, and the original locations of the vertices
should not have any affection at all. In this case you would want to make
sure that your entire mesh is enclosed by the fields.
I still don't know what would be the best way to define the fields with.
Patterns, blob-like fields, maybe both options, or maybe something entirely
different?
I personally think blob-like fields would be best. Remember that possible
patterns would not deform the mesh directly, but only be used as weights for
some linear transformations. Therefore I think the usefulness of complicated
patters to control this is rather limited.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] inamecom> wrote:
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...
>
> I suggest that we begin to think of the possibilities of implementing such
> functions. I personally believe that it could improve POV-Ray
significantly
> in some of the areas where it is currently not as powerful as many other
> renderers.
>
> To make such functions useable it would probably be necessary to implement
> several different kinds of those nonlinearly transformations. They could
all
> be contained into a statement such as deform {} or something.
>
> One type of deform could be one that deforms dependent on warps:
>
> deform {
> warp {...}
> }
>
> As you can sure imagine, this alone would be a very powerful and general
way
> of deforming the supported object.
>
> But more complicated ways of deforming may be useful. I have thought of a
> feature that would deform objects by several user-specified regular
> transforms, each weighted by a 3D field in space. I believe this could be
> used for many things. For example it could be used to make a kind of bone
> structure. One part of a mesh body could be enclosed by one field which
> would be transformed by one linear transform. Another part of the body
would
> by due to another field be transformed by another linear transform. The
> 3D-fields could be defined by patterns, which would be very flexible, but
> probably also rather difficult to master and somewhat slow, or they could
be
> controlled in a way similar to blobs, which would be less flexible, but
> surely easier to understand, and probably faster. Possible syntax:
>
> deform {
> field_transform {
> sphere {
> location, radius, strength,
> transformations (of the field)
> apply_transform transform_id (of the mother object, such as mesh)
> }
> cylinder { (like sphere, but with end1, end2 instead of location) }
> ...
> }
> }
>
> alternative way:
>
> deform {
> field_transform {
> field {pattern_id, transform_id}
> field {pattern_id, transform_id}
> ...
> }
> }
>
> The pattern way of field_deform could be used with blob_pattern to achieve
> same functionality I guess, but it would probably still be slower.
>
> Other deform types could possible be made too. What do you think of the
> whole idea?
If you would like to experiment a little with mesh and patch deformations,
without modifying the POV code just yet, perhaps you should look at the
Compressed Mesh macro file in conjunction with Warp's Mesh Compressor:
http://www.geocities.com/ccolefax
The Compressor and Macros combined give you access to the vertices of meshes
(including bicubic patch models), and you are free to warp these at will.
Using various MegaPOV features (such as eval_pigment), you could even try
out ideas like your pattern warps.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|