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] 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

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

"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

it's not just technical. just imagine what it would be like if we started to
have scene files floating around that depended on a particular mod being
loaded. it'd fragment POV's standard, work-on-any-platform scene language
into a bunch of platform-specific dialects.

Post a reply to this message

I have to agree, I think the team has made a good effort in keeping it
standradized. As for that, What is it that _must_ be in a separate dll,
that can't be linked in in a header file ?


//Spider

Post a reply to this message

How would this be different than having to use say the SuperPatch
version to render something?  I'm not really seeing the distinction.

Steve


"povray.org admin team" wrote:
> 
> "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
> 
> it's not just technical. just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

Post a reply to this message

On Tue, 09 Feb 1999 19:50:06 GMT, povray.org admin team 
	<new### [at] DESPAMpovrayorg> wrote:
>"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
>
>it's not just technical. just imagine what it would be like if we started to
>have scene files floating around that depended on a particular mod being
>loaded. it'd fragment POV's standard, work-on-any-platform scene language
>into a bunch of platform-specific dialects.

As if that problem weren't already pretty severe with all the various 
patches out there.  If the cross-platform and other portability issues 
were resolved, though, I can see where the plugin concept would cause 
less of this problem than does the current system - especially if there
were a more-or-less centralized repository for plugins and if they were
required to be covered under either POVLEGAL or an Open Source license 
of some form.

At least with plugins, or the underlying architecture they'd require, 
adding most new unofficial features would be easier than modifying the 
current minimum of three files[1], if you should happen to need to 
recompile the plugin for your OS.  Having been through the process of 
merging sometimes-incompatible unofficial features[2] more times than 
I care to count, I can testify that it's often much more difficult than 
modifying a handful of files.  It shouldn't have to be that hard to
just add a new object, function, or texture.

[1] parse.h, [parse|parstxtr|express].c, tokenize.c
[2] and some official ones - most of the patches in the Superpatch 
    were originally written for version 3.0x and were originally 
    merged with that source base, so I merged in version 3.1 as if 
    it were just another patch.

Post a reply to this message

I don't think this would be tragic.  A cross-platform core could 
be supplimented with external libraries.  I don't see a bit problem
with this -- those wishing to publish public code will stick to the
core, while individual users will be able to exploit what is available
for their particular system.  It's better than holding everyone to
a minimal common denominator.

Things which encourage innovation and experimentation should in general
be pursued, not avoided.

Dan

"povray.org admin team" wrote:
> 
> it's not just technical. just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

My opinion could sway to either side of this debate.
I once tried changing 'phong' and 'phong_size' to "gloss" and
"gloss_used" just for aesthetics, to use a more household word instead.
I went so far as to convert a few scene files so the name changes could
be recognized and made a few more new scenes too. BTW, I had to also
change my _surface.inc (customized finish.inc) and several other
includes to work with this custom pvengine.exe.
It wasn't long before I switched back due to the incompatiblity with so
many files, old or new. I still have custom includes I use for
everything from colors (_color.inc) to woods.inc (_wood.inc) which in
itself is not too compatible outside of my own environment here. Sure,
all the original stuff is still in them, but if I get an outside source
that requires the colors.inc, textures.inc, etc., I have to change those
filenames or leave copies of the originals around.
As you can see the ability to customize so many aspects can get garbled
in the translation. Even though I've heard mention before of
customizable keywords (which I found, during all that, keywords can't be
re-defined using #declare to solve the custom keyword problem) it
obviously gets chaotic enough just adding new includes that have to be
passed around to ensure renderability (don't we all know it!).
Guess that kind of goes with the territory though, which is why I said I
could see it both ways, but not easily. All in all, the argument for,
rather than against, plug-ins as stated by others seems a valid point.


"povray.org admin team" wrote:
> 
> just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
=Bob

Post a reply to this message