 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This deals with the mesh, specifically, an idea for a new kind of
triangle to go into the mesh, one that maintains its appearance
when animated.
Let's say that you have a mesh of a lizard, to which a texture with
a crackle pattern is applied. This can look excellent, depending
on how good you are with textures. However, if the mesh is animated,
for example by moving the legs of the lizard, the pattern does not
move with the lizard, but says put in 3d space, while the triangles
that form the mesh move. The result is a shifting pattern on the
lizard's skin that is unrealistic.
There is one work-around, and that is to declare a texture for
each and every triangle. This is not terribly difficult, and can
be easily automated in .INC files, but the memory requirements are
enormous.
Another solution, which would have to be implemented in the renderer,
involves having an extra set of points for each triangle, which defines
a source triangle for texturing. The syntax would look like this:
stretch_triangle {
RealPointA,TexturePointA,NormalA,
RealPointB,TexturePointB,NormalB,
RealPointC,TexturePointC,NormalC
texture { DeclaredTexture }
}
It would have the appearance of a triangle that was originally declared
at (TexturePointA,TexturePointB,TexturePointC) with a static texture
and then transformed to appear at (RealPointA,RealPointB,RealPointC).
Implementation seems simple (real programmers, please comment!): After
the surface-ray intersection test, transform the point to convert from
a point on (RA,RB,RC) to the corresponding point on triangle (TPA,TPB,TPC).
The specifics of the texture at that point are used to determine
color and shading for the original point of intersection.
If I estimate things correctly, the only additional memory requirements
would be for the inversion matrix, which can be truncated to 12 variables,
since the fourth column is invariably (0,0,0,1). The double-precision
values take eight bytes, therefore the inverse matrix requires 96 bytes;
this does not seem unreasonable for the benefit to be gained. The
present alternative--building a new texture for each triangle--appears to
consume at least twice that much memory.
If it's feasible, this would greatly extend the mesh feature, and allow
for effects like the stretching of skin, the waving of a flag, etc, to be
easily modeled.
So, what do you all think?
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I'm no programmer, so I can't tell you anything about the
feasibility, but I can say that it's A GREAT IDEA! I can definately see
some applications for it, and now I'm wondering "how did I ever live
without it?"
You have my support for sure :-)
Kyle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote in message <36BDE61D.E07EAEDB@erols.com>...
>This deals with the mesh, specifically, an idea for a new kind of
>triangle to go into the mesh, one that maintains its appearance
>when animated.
>
>Let's say that you have a mesh of a lizard, to which a texture with
>a crackle pattern is applied. This can look excellent, depending
>on how good you are with textures. However, if the mesh is animated,
>for example by moving the legs of the lizard, the pattern does not
>move with the lizard, but says put in 3d space, while the triangles
>that form the mesh move. The result is a shifting pattern on the
>lizard's skin that is unrealistic.
>
/.../
Wouldn't UV mapping do the trick?
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> John VanSickle wrote in message <36BDE61D.E07EAEDB@erols.com>...
> >This deals with the mesh, specifically, an idea for a new kind of
> >triangle to go into the mesh, one that maintains its appearance
> >when animated.
> >
> >Let's say that you have a mesh of a lizard, to which a texture with
> >a crackle pattern is applied. This can look excellent, depending
> >on how good you are with textures. However, if the mesh is animated,
> >for example by moving the legs of the lizard, the pattern does not
> >move with the lizard, but says put in 3d space, while the triangles
> >that form the mesh move. The result is a shifting pattern on the
> >lizard's skin that is unrealistic.
> >
> /.../
>
> Wouldn't UV mapping do the trick?
This could be seen as an alternative form of UV mapping, I suppose.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
>
> This could be seen as an alternative form of UV mapping, I suppose.
Actually, it is quite standard. Assignment of uv coordinates
to mesh nodes is a standard feature of many mesh formats (OBJ,
for example), including the updated POV mesh format supported
in Kopp's Patched POV ( http://nathan.kopp.com/patched.htm ).
See http://nathan.kopp.com/meshes.htm for details, from which
the following example is an extract. Note the "uv_vectors" specify
the coordinates -- thus your lizard's skin won't creep.
Dan
-----------------
vertex_vectors
{
number_of_vertices,
<vertex1>, <vertex2>, ...
}
normal_vectors
{
number_of_normals,
<normal1>, <normal2>, ...
}
uv_vectors
{
number_of_uv_vectors,
<uv_vect1>, <uv_vect2>, ...
}
texture_list
{
number_of_textures,
texture { Texture1 },
texture { Texture2 }, ...
}
face_indices
{
number_of_faces,
<index_a, index_b, index_c>, [texture_index],
<index_d, index_e, index_f>, [texture_index],
...
}
normal_indices
{
number_of_faces,
<index_a, index_b, index_c>,
<index_d, index_e, index_f>,
...
}
uv_indices
{
number_of_faces,
<index_a, index_b, index_c>,
<index_d, index_e, index_f>,
...
}
[object modifiers]
}
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(apologies if this goes out twice... Netscape crashed on me
during my first attempt)
John VanSickle wrote:
>
> This could be seen as an alternative form of UV mapping, I suppose.
Actually, it is quite standard. Assignment of uv coordinates
to mesh nodes is a standard feature of many mesh formats (OBJ,
for example), including the updated POV mesh format supported
in Kopp's Patched POV ( http://nathan.kopp.com/patched.htm ).
See http://nathan.kopp.com/meshes.htm for details, from which
the following example is an extract. Note the "uv_vectors" specify
the coordinates -- thus your lizard's skin won't creep.
Dan
-----------------
vertex_vectors
{
number_of_vertices,
<vertex1>, <vertex2>, ...
}
normal_vectors
{
number_of_normals,
<normal1>, <normal2>, ...
}
uv_vectors
{
number_of_uv_vectors,
<uv_vect1>, <uv_vect2>, ...
}
texture_list
{
number_of_textures,
texture { Texture1 },
texture { Texture2 }, ...
}
face_indices
{
number_of_faces,
<index_a, index_b, index_c>, [texture_index],
<index_d, index_e, index_f>, [texture_index],
...
}
normal_indices
{
number_of_faces,
<index_a, index_b, index_c>,
<index_d, index_e, index_f>,
...
}
uv_indices
{
number_of_faces,
<index_a, index_b, index_c>,
<index_d, index_e, index_f>,
...
}
[object modifiers]
}
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <van### [at] erols com> wrote:
: This could be seen as an alternative form of UV mapping, I suppose.
I think that it's not an alternative to UV-mapping, but actually you
really were talking about UV-mapping.
Does the uv-mapping patch support uv-mapping for procedural textures or
only for bitmaps?
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The uv patch supports both bimaps and procedural textures.
Margus
Nieminen Mika wrote:
>
> John VanSickle <van### [at] erolscom> wrote:
> : This could be seen as an alternative form of UV mapping, I suppose.
>
> I think that it's not an alternative to UV-mapping, but actually you
> really were talking about UV-mapping.
> Does the uv-mapping patch support uv-mapping for procedural textures or
> only for bitmaps?
>
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote in message <36BEE54F.1099D40A@peak.edu.ee>...
>The uv patch supports both bimaps and procedural textures.
>
>Margus
>
>Nieminen Mika wrote:
>>
>> John VanSickle <van### [at] erolscom> wrote:
>> : This could be seen as an alternative form of UV mapping, I suppose.
>>
>> I think that it's not an alternative to UV-mapping, but actually you
>> really were talking about UV-mapping.
>> Does the uv-mapping patch support uv-mapping for procedural textures or
>> only for bitmaps?
Grr... I know this have been brought up before, but why can't POV accept
dlls to add new features to it, like Moray? Yes, I know they're platform
specific - but it would be great if this ability could be added even just to
the Windows version. Yeah, sure - I suppose they'd be quite a technical
problems (like what sort of procedures would be required in the first place
to write the dlls) but I can only hope ;)
From someone that prefers to only use the official POV binaries, it's
annoying to see so many great ideas/features only available from
"home-built" patched versions. :(
Just my 2 pence,
Matt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 8 Feb 1999 19:22:00 -0000, Matthew Bennett
<ben### [at] btinternetcom> wrote:
>Grr... I know this have been brought up before, but why can't POV accept
>dlls to add new features to it, like Moray? Yes, I know they're platform
>specific - but it would be great if this ability could be added even just to
>the Windows version. Yeah, sure - I suppose they'd be quite a technical
>problems (like what sort of procedures would be required in the first place
>to write the dlls) but I can only hope ;)
I considered doing this at one point, and I even sent a (rough)
proposal to the POV Team about it, since doing anything with it
would require a variance to POVLEGAL. Last I heard, they were
going to revisit it after 3.1 was out the door. Obviously 3.1
has shipped, but since I don't have time to actually do the project
right now anyway, I haven't bothered trying to shepherd the proposal
back onto their schedules. The cross-platform stuff isn't as bad
as it looks - most modern operating systems support dynamic linking
in one form or another, and the rest (i.e. DOS) would still benefit
from the greater organization inherent in the plugin model. Still,
Chris Young has indicated that dynamic loading is not something the
Team wants to think about, as evidenced by the likely removal of
"function library" support from the isosurface patch if and when it
is made official.
You should know, though, that a lot of the less simple patches,
including the UV mapping patch, would be difficult to fit into
any kind of simple plugin model anyway.
>From someone that prefers to only use the official POV binaries, it's
>annoying to see so many great ideas/features only available from
>"home-built" patched versions. :(
Chris Young has said that they're seriously looking at all of the
available patches with an eye toward including some of them in
version 3.5. We'll all just have to sit back and see what happens.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
