 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm wondering about the possible tesselation of Pov object:
would you expect the textures of the tesselated object to be taken in the generated
mesh ?
Or would you only expect to get the form with only the default texture ?
Or something else ?
Should the actual texture be used?
or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
P.S.: Cross-posted in p.g and p.u.p, FU2 set to p.u.p
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 18 Feb 2002 12:49:56 +0100, J�r�me Grimbert
<jer### [at] atosorigin com> wrote:
> I'm wondering about the possible tesselation of Pov object:
This question sounds great becouse it's suggestion you are near final
implementation.
> would you expect the textures of the tesselated object to be taken in the generated
mesh ?
> Or would you only expect to get the form with only the default texture ?
> Should the actual texture be used?
> or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
I imagine all above should be optional. For example: there is no simple way to
recreate texture of differently colored blob's components, so sampling colors
(or even all texture components) for vertices should be possible. But when
complicated iso-stone is tesselated then there is no need to store texture for
every vertex but whole mesh should inherit texture from mesh.
Also it could be great to inherit uv-coordinates when available. For example
parametric object is very slow in rendering but looks it could be possible to
apply uv-mapping to it. Recreating this object with loop along functions gives
not optimized mesh. Recreating it with tesselation gives optimized triangles
but without uv-mapping.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3C70EA64.D2E842C9@atosorigin.com Jérôme Grimbert wrote:
> would you expect the textures of the tesselated object to be taken in
> the generated mesh ?
No.
> Or would you only expect to get the form with
> only the default texture ?
Yes, as it is not a copy of an object but a new one.
> Or something else ?
uv-coordinates?
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W³odzimierz ABX Skiba" wrote:
>
> On Mon, 18 Feb 2002 12:49:56 +0100, Jérôme Grimbert
> <jer### [at] atosorigincom> wrote:
> > I'm wondering about the possible tesselation of Pov object:
>
> This question sounds great becouse it's suggestion you are near final
> implementation.
>
Sort of, I currently have 6 differents ways to tesselate an object:
2 based on marching tetrahedrons, using intersection test (IIRC);
4 based on marching cube, using insideness and various way to do the triangles;
(but for the latest 2, I still need to check the PD aspect of the tesselation,
because what I can do ok in my kitchen might not be ok in exported code.)
All workings fine with sphere/box/cone/cylinder/torus, but still need to check
with more fancy objects (such as julia_fractal, blob, CSG and so on...).
> > would you expect the textures of the tesselated object to be taken in the
generated mesh ?
> > Or would you only expect to get the form with only the default texture ?
> > Should the actual texture be used?
> > or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
>
> I imagine all above should be optional.
That's not really an answer.
May be, the intersection test based could get a copy of the texture structure at
the intersection,
Whereas the ones using insideness might just inherit a texture if explicitely
specified by the SDL ?
> For example: there is no simple way to
> recreate texture of differently colored blob's components, so sampling colors
> (or even all texture components) for vertices should be possible. But when
> complicated iso-stone is tesselated then there is no need to store texture for
> every vertex but whole mesh should inherit texture from mesh.
I will have to think about that too! Thanks.
>
> Also it could be great to inherit uv-coordinates when available. For example
> parametric object is very slow in rendering but looks it could be possible to
> apply uv-mapping to it. Recreating this object with loop along functions gives
> not optimized mesh. Recreating it with tesselation gives optimized triangles
> but without uv-mapping.
That's a different problem. It would be optimising the parametric object,
not tesselating any solid finite object.
For the time being, I will just forget about UV-mapping for general tesselation.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Feb 2002 07:43:02 -0500, ingo <ing### [at] homenl> wrote:
> > Or would you only expect to get the form with
> > only the default texture ?
>
> Yes, as it is not a copy of an object but a new one.
IIRC every object in POV (except mesh and parametric) is new one becouse has
own memory representation. Why not to allow optional behaviour ? In case of
tesselated blob it could be very difficoult to recreate texture for mesh.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
>
> in news:3C70EA64.D2E842C9@atosorigin.com Jérôme Grimbert wrote:
>
> > would you expect the textures of the tesselated object to be taken in
> > the generated mesh ?
>
> No.
>
> > Or would you only expect to get the form with
> > only the default texture ?
>
> Yes, as it is not a copy of an object but a new one.
Ok, that would be simpler for the code.
>
> > Or something else ?
>
> uv-coordinates?
Sincerely, forgets about UV, because there is no way to do that for
all finite solid objects.
Even if one only considers the UV mapping of a sphere, the UV mapping of
the union of two spheres is mind-boggling and too hard to generalise.
But I notice that sampling RGB at the vertices does not seems to suit either.
Ok.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 18 Feb 2002 13:50:37 +0100, J�r�me Grimbert
<jer### [at] atosorigincom> wrote:
> > I imagine all above should be optional.
>
> That's not really an answer.
> May be, the intersection test based could get a copy of the texture structure at
> the intersection,
> Whereas the ones using insideness might just inherit a texture if explicitely
> specified by the SDL ?
So do it at least for intersection methids (if I understand your answer
correctly)
>For the time being, I will just forget about UV-mapping for general tesselation.
:-(
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert wrote:
>
> [...]
>
> Sort of, I currently have 6 differents ways to tesselate an object:
> 2 based on marching tetrahedrons, using intersection test (IIRC);
> 4 based on marching cube, using insideness and various way to do the triangles;
> (but for the latest 2, I still need to check the PD aspect of the tesselation,
> because what I can do ok in my kitchen might not be ok in exported code.)
>
> All workings fine with sphere/box/cone/cylinder/torus, but still need to check
> with more fancy objects (such as julia_fractal, blob, CSG and so on...).
>
How about adaptive (curvature or distance dependant) methods. See for
example:
http://www.cs.queensu.ca/home/jstewart/papers/cga01.html
I think some kind of adaptation would be possible with a marching
algorithm too.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> How about adaptive (curvature or distance dependant) methods. See for
> example:
>
> http://www.cs.queensu.ca/home/jstewart/papers/cga01.html
From Page 2:
The algorithm requires an evaluator for the implicit function defined at all points in
space,
an evaluator for the function gradient defined at points near the surface,
and a bounding box around the surface.
The bounding box, we have.
Alas, the only function available is "Insideness test", and the result is only 0 or 1
(usually).
So, no easy way to have an evaluator for the gradient (we could make one based
on soft variation of the value of the implicit function, if the answer was smoother).
But even requiring each Pov-object to provide this kind of function is probably not
worth it, because of the various transformation that might apply to an object.
Anyway, try getting a smooth evaluation for a julia_fractal, it might be possible
but really horrible.
The link may nevertheless be of interest for optimisation of the parametric object,
which I do not know.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert wrote:
>
> > http://www.cs.queensu.ca/home/jstewart/papers/cga01.html
>
> From Page 2:
> The algorithm requires an evaluator for the implicit function defined at all points
in space,
> an evaluator for the function gradient defined at points near the surface,
> and a bounding box around the surface.
>
> [...]
I mainly cited this paper since it also mentions some other tesselation
methods producing curvature dependant resolution meshes.
An algorithm only suited for isosurfaces might be useful though since a
lot of basic shapes can be represented as isosurfaces without problems.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C70EA64.D2E842C9@atosorigin.com>,
Jérôme Grimbert <jer### [at] atosorigincom> wrote:
> I'm wondering about the possible tesselation of Pov object:
>
> would you expect the textures of the tesselated object to be taken in the
> generated mesh ?
> Or would you only expect to get the form with only the default texture ?
> Or something else ?
I don't see a reason for an object rendered using tesselation to have a
different texture. I'm assuming tesselation is done as an object option
though, not as generating a new object.
> Should the actual texture be used?
> or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
The actual texture. Vertex coloring would require a high-resolution mesh
just for proper texturing, but that won't work for some objects (for
example, a box can be tesselated with just 12 triangles, and a plane
with 2, and a triangle with 1).
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> In article <3C70EA64.D2E842C9@atosorigin.com>,
> Jérôme Grimbert <jer### [at] atosorigincom> wrote:
>
> > I'm wondering about the possible tesselation of Pov object:
> >
> > would you expect the textures of the tesselated object to be taken in the
> > generated mesh ?
> > Or would you only expect to get the form with only the default texture ?
> > Or something else ?
>
> I don't see a reason for an object rendered using tesselation to have a
> different texture. I'm assuming tesselation is done as an object option
> though, not as generating a new object.
I think that it would be a great pity if
a POV-patch were to perform tessellation
of an object without providing the possi-
bility to texture different copies of it
differently.
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C7### [at] onlineno>,
Tor Olav Kristensen <tor### [at] onlineno> wrote:
> I think that it would be a great pity if
> a POV-patch were to perform tessellation
> of an object without providing the possi-
> bility to texture different copies of it
> differently.
I wasn't talking about copies, but an alternate rendering method. A
"tesselate" flag that would cause the object to be tesselated and
rendered (and traced) as a mesh. Copies would be textured the same way
any other object copies are textured.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> I wasn't talking about copies, but an alternate rendering method. A
> "tesselate" flag that would cause the object to be tesselated and
> rendered (and traced) as a mesh. Copies would be textured the same way
> any other object copies are textured.
Well, I wasn't talking about tesselating for rendering but mainly to
get an mesh object. What is done with the mesh is then upto the user.
It would be rendered at the end, but also may be in the meantime some non-linear
transformation might be performed on it.
Or thousand of copies of the mesh made, instead of thousand of copies of
some memory consuming objects.
Or whatever the user wants.
The main objective I want to stick with is:
One object (which might be very complex, but it is bounded, finite and solid) is
provided,
you get back a closed mesh which is somehow similar to the provided object.
I do not want to make any change in the rendering engine.
I do not want to provide a global setting which would tesselate all objects in a scene
before rendering the tesselated set of objects.
It's just a kind of 'avoid the modeler & parsing time of mesh files'.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sort of, I currently have 6 differents ways to tesselate an object:
> 2 based on marching tetrahedrons, using intersection test (IIRC);
> 4 based on marching cube, using insideness and various way to do the
triangles;
> (but for the latest 2, I still need to check the PD aspect of the
tesselation,
> because what I can do ok in my kitchen might not be ok in exported code.)
>
> All workings fine with sphere/box/cone/cylinder/torus, but still need to
check
> with more fancy objects (such as julia_fractal, blob, CSG and so on...).
have you considered assigning standard pov objects (eg sphere) a pre defined
mesh, marching for all non regular objects (such as blobs) then deal with
csg
--
Rick
Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
> have you considered assigning standard pov objects (eg sphere) a pre defined
> mesh, marching for all non regular objects (such as blobs) then deal with
> csg
Sorry to sound offensive but:
<Irony on>
Please do the same for UV-Mapping first,
then I will slaveshly copy your solution to perform tesselation.
Afterall, UV mapping is present in megapov since so much time...
<Irony off>
Just think about both problem, they are very similar.
To reassure you, I should post soon a tesselation of a sphere in p.b.i.
(Low resolution of tessel, unsmoothed mesh). How many slice do you want ?
Do you have any other fetish object that you (or someone else) would like
to see tesselated ? (you provide the code or the pointer to it !)
P.S.: To really answer your question, Yes I did, and I consider it was
not forth it (adding pre-tesselated primitive) as long as the marching
variant were able to provide a good result. And most mesh are not simple
primitive anyway. With the marching approach, I have a hammer, so everything
is going to be a nail !
(But I have different hammers (6), not just one big universal one...)
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 19 Feb 2002 13:44:25 +0100, J�r�me Grimbert
<jer### [at] atosorigincom> wrote:
> Do you have any other fetish object that you (or someone else) would like
> to see tesselated ?
new povlogo
it's realy is good testing object: cone, sphere, difference, union,
translations, rotations, splitted volume, sharp edges, smooth surface
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme Grimbert" <jer### [at] atosorigincom> wrote in message
news:3C7248A9.A515605B@atosorigin.com...
> To reassure you, I should post soon a tesselation of a sphere in p.b.i.
> (Low resolution of tessel, unsmoothed mesh). How many slice do you want ?
> Do you have any other fetish object that you (or someone else) would like
> to see tesselated ? (you provide the code or the pointer to it !)
>
My car =)
http://news.povray.org/povray.binaries.scene-files/22093/150317/NekCar_F15.pov
http://news.povray.org/povray.binaries.scene-files/22093/150317/Car_F15.inc
I wonder how long it would take to tessellate it...
--
#local X=20*<-2,2,5>;#local K=2*z*X-X;#local R=seed(frame_number);blob{#while(K
.x>X.x)#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X
-N);sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{
emission<2,4,5>*5}}hollow scale.05}// http://nekar_xenos.tripod.com/metanoia/
sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<8,-8>1<8,8>1<8,8>1
translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9,18>][1rgb 0]}}}
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.324 / Virus Database: 181 - Release Date: 2002/02/14
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos wrote:
> My car =)
> ...
You and that car... I think you're obssessed ;)
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
None of that would be a problem.
This is what I'm thinking:
1: A "tesselate" flag for each shape. Some shapes (simple ones like
spheres, cylinders, boxes, triangles, polygons, meshes, height
fields...) will have specialized tesselation methods, the rest will use
the generic methods. I actually got most of the work on this done using
Warp's tesselation code, but never finished it.
When the tesselate flag is specified, the object is tesselated. Copies
of it share the same mesh data, unless tesselation is specified for the
copy, in which case it gets its own mesh (useful if you want multiple
copies with different tesselation parameters). The resulting object uses
the mesh for intersection calculations, but the original insideness
calculations, so it is still useful for CSG.
2: Objects can be used in a mesh statement. The object is then
tesselated and the resulting triangles placed in the mesh. The
"tesselate" flag is used to give any special settings to the tesselation
code, if not specified the defaults are used.
3: Possibly, allow non-linear deformations for all shapes. Those shapes
that don't support a more direct method will tesselate and deform the
mesh.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> In article <3C7### [at] onlineno>,
> Tor Olav Kristensen <tor### [at] onlineno> wrote:
>
> > I think that it would be a great pity if
> > a POV-patch were to perform tessellation
> > of an object without providing the possi-
> > bility to texture different copies of it
> > differently.
>
> I wasn't talking about copies, but an alternate rendering method. A
> "tesselate" flag that would cause the object to be tesselated and
> rendered (and traced) as a mesh. Copies would be textured the same way
> any other object copies are textured.
I am hoping for the possibility to tweak
the individual copies of a mesh before
texturing them.
If one has direct access to the 3D coordinates
of the vertexes and the normal vectors, then
the tessellated shapes could be transformed
in very weird ways.
(POV's usual matrix<> related transformations
would only allow for linear transformations.)
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C72EE49.979B5315@hotmail.com>,
Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
> I am hoping for the possibility to tweak the individual copies of a
> mesh before texturing them.
I don't see how it would be a problem...just include a
"preserve_textures" option for objects being added to meshes. If it is
on, the triangles get the texture of the original object, if it is off
you get an untextured mesh.
> If one has direct access to the 3D coordinates of the vertexes and
> the normal vectors, then the tessellated shapes could be transformed
> in very weird ways.
I once attempted a patch that would allow any warp to be applied to a
mesh...my only problem was that I couldn't seem to move the mesh points.
My attempts all resulted in "scrambled triangles".
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Do you have any other fetish object that you (or someone else) would like
> to see tesselated ? (you provide the code or the pointer to it !)
When my cloth-fur-thing has managed to produce something nice (like a towel
or maybe even a sitting poodle), I'll let you (or your program or your
script) tesselate it. And then maybe there are some fetishists that are
willing to recreate it with snippets of paper in real life. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Grey Knight" <s16### [at] namtarqubacuk> wrote in message
news:3C726191.7E0F3F4A@namtar.qub.ac.uk...
> Nekar Xenos wrote:
> > My car =)
> > ...
>
> You and that car... I think you're obssessed ;)
>
Yeah.. ;o)
--
#local X=20*<-2,2,5>;#local K=2*z*X-X;#local R=seed(frame_number);blob{#while(K
.x>X.x)#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X
-N);sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{
emission<2,4,5>*5}}hollow scale.05}// http://nekar_xenos.tripod.com/metanoia/
sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<8,-8>1<8,8>1<8,8>1
translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9,18>][1rgb 0]}}}
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.325 / Virus Database: 182 - Release Date: 2002/02/19
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> In article <3C72EE49.979B5315@hotmail.com>,
> Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
>
> > I am hoping for the possibility to tweak the individual copies of a
> > mesh before texturing them.
>
> I don't see how it would be a problem...just include a
> "preserve_textures" option for objects being added to meshes. If it is
> on, the triangles get the texture of the original object, if it is off
> you get an untextured mesh.
Ok, looks like we are going for the 'all option' versions...
It seems there is two opposite approachs, each with good arguments.
It might be better afterall, but it will be harder for me...
> > If one has direct access to the 3D coordinates of the vertexes and
> > the normal vectors, then the tessellated shapes could be transformed
> > in very weird ways.
>
> I once attempted a patch that would allow any warp to be applied to a
> mesh...my only problem was that I couldn't seem to move the mesh points.
> My attempts all resulted in "scrambled triangles".
I'm sorry, really sorry... I made such thing last weeks... :-< ... and it works fine.
Just currently, it is just forgetting to copy individual textures... and
smooth triangles do not survive as smooth...
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3C7### [at] onlineno>,
> Tor Olav Kristensen <tor### [at] onlineno> wrote:
>
> > I think that it would be a great pity if
> > a POV-patch were to perform tessellation
> > of an object without providing the possi-
> > bility to texture different copies of it
> > differently.
>
> I wasn't talking about copies, but an alternate rendering method. A
> "tesselate" flag that would cause the object to be tesselated and
> rendered (and traced) as a mesh. Copies would be textured the same way
> any other object copies are textured.
Question: Would it be appropriate for, say, "tesselation" to have it's own
block of code inside the object declaration (the same way as texture, media,
interior, etc)? This way, all tessellation-only transformations /
deformations whatever get grouped together for easy reference.
...Chambers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
>
> "Christopher James Huff" <chr### [at] maccom> wrote in message
> > I wasn't talking about copies, but an alternate rendering method. A
> > "tesselate" flag that would cause the object to be tesselated and
> > rendered (and traced) as a mesh. Copies would be textured the same way
> > any other object copies are textured.
I do not like that idea of flag.
>
> Question: Would it be appropriate for, say, "tesselation" to have it's own
> block of code inside the object declaration (the same way as texture, media,
> interior, etc)? This way, all tessellation-only transformations /
> deformations whatever get grouped together for easy reference.
I still think that a tesselated object is just an object, and that deformation
of mesh are still another object whose parameter is an input mesh and some
additional parameters.
Having a 'tesselation' block would mean to provide a view to the user which
would really be very different from the internal: because the user would see
it as an extension of any object, whereas in real code, the object would
have been completely replaced by something else.
Moreover, some object won't be able to support this block, which is really
annoying because it breaks the homogeneity of the 'object' in Pov.
Last, I do not believe that transformation of mesh are similar to blob component:
the order in which the transformation are made usually is important.
So adding a 'tesselation block' would means to have something similar to
layered texture, which would just prouve to be counter-productive for mesh
transformation in the current state of the code.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7498ae@news.povray.org>,
"Ben Chambers" <bdc### [at] yahoocom> wrote:
> Question: Would it be appropriate for, say, "tesselation" to have it's own
> block of code inside the object declaration (the same way as texture, media,
> interior, etc)? This way, all tessellation-only transformations /
> deformations whatever get grouped together for easy reference.
I don't see why this would be useful, and it would be very inconsistent.
All it would do is complicate the programming, it wouldn't add any
flexibility.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C74BB1F.D2267C56@atosorigin.com>,
Jérôme Grimbert <jer### [at] atosorigincom> wrote:
> I still think that a tesselated object is just an object,
Agreed.
> and that deformation of mesh are still another object whose parameter
> is an input mesh and some additional parameters.
Hmm? Are you talking about some sort of "deform" object that takes a
mesh as input? That might be what was wrong with my approach, I was
attempting to deform a mesh, with a syntax more like transformations.
> Having a 'tesselation' block would mean to provide a view to the user which
> would really be very different from the internal: because the user would see
> it as an extension of any object, whereas in real code, the object would
> have been completely replaced by something else.
This sort of thing is done already: bicubic patches and height fields
are reduced to triangles internally, and some objects have a "sturm"
option to change the intersection solver. The tesselate flag wouldn't
replace the object, it would just tell it to use a mesh for the
intersection calculations. It could even use the object's own normal and
insideness calculations. The flag wouldn't be used for deformation or
anything, just for intersection. Some other method would be used to
generate a mesh, I'd suggest something like: mesh {OBJECT} or tesselate
{OBJECT}.
> Moreover, some object won't be able to support this block, which is really
> annoying because it breaks the homogeneity of the 'object' in Pov.
Which objects? The only ones I can think of are the infinite ones, and a
stand-in could be generated for those...two very big triangles for the
plane, for example. And these objects have to be dealt with anyway, what
does your patch currently do?
> Last, I do not believe that transformation of mesh are similar to blob
> component:
> the order in which the transformation are made usually is important.
> So adding a 'tesselation block' would means to have something similar to
> layered texture, which would just prouve to be counter-productive for mesh
> transformation in the current state of the code.
I don't understand...what do blobs have to do with this? Did I miss
something?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> In article <3C74BB1F.D2267C56@atosorigin.com>,
> Jérôme Grimbert <jer### [at] atosorigincom> wrote:
>
> > I still think that a tesselated object is just an object,
>
> Agreed.
>
> > and that deformation of mesh are still another object whose parameter
> > is an input mesh and some additional parameters.
>
> Hmm? Are you talking about some sort of "deform" object that takes a
> mesh as input? That might be what was wrong with my approach, I was
> attempting to deform a mesh, with a syntax more like transformations.
>
Yes.
> > Last, I do not believe that transformation of mesh are similar to blob
> > component:
> > the order in which the transformation are made usually is important.
> > So adding a 'tesselation block' would means to have something similar to
> > layered texture, which would just prouve to be counter-productive for mesh
> > transformation in the current state of the code.
>
> I don't understand...what do blobs have to do with this? Did I miss
> something?
Just my mind wandering about the possible 'tesselation' block
(which is a bad idea, IMNSHO, at least with my current code).
Order in blob is irrelevant, whereas order of transformation is important,
even if the rotate/scale/translate can all be summarized in one single
matrix, but for transformation of mesh there is no possible summarisation, and
order is still important.
I should probably not have mentionned the blob.
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert wrote:
>
> [...]
> Having a 'tesselation' block would mean to provide a view to the user which
> would really be very different from the internal: because the user would see
> it as an extension of any object, whereas in real code, the object would
> have been completely replaced by something else.
I second that.
Although Chris Huff is right that there are objects internally represented
as a mesh (like heightfield and patch) this is something different IMO. A
method for combining different meshes into one would be good of course.
I think a syntax like ABX suggested in p.b.i would be best:
tesselate{
OBJECT_ID | OBJECT
METHOD { METHOD_PARAMS }
WARP { WARP_STATEMENT } | DISPLACEMENT{ PIGMENT |
f_x(x,y,z),f_y(x,y,z),f_z(x,y,z) }
OBJECT_MODS
}
Although i think the 'DISPLACEMENT' is unnecessary if we have displace
warps or function warps (which would be based on a vector function)
No matter what syntax is chosen there should be a save_file/load_file
possibility, maybe with different possible file formats (mesh, mesh2, pcm)
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> A method for combining different meshes into one would be good of course.
As I'm overusing the foundation made by Warp in his tesselation patch,
the good news is that there is already such things:
mesh { tesselate {.... } tesselate {...} triangle.... }
> No matter what syntax is chosen there should be a save_file/load_file
> possibility, maybe with different possible file formats (mesh, mesh2, pcm)
that's a mesh level problem, not particular to the tesselation patch.
You want file I/O for mesh, and there was already a macro/include file
to do that (based on Warp extension to access the mesh structure from SDL).
And soon, you will want a full dump of all Pov-scene...
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert wrote:
>
> [...]
>
> As I'm overusing the foundation made by Warp in his tesselation patch,
> the good news is that there is already such things:
>
All right, that's fine.
>
> > No matter what syntax is chosen there should be a save_file/load_file
> > possibility, maybe with different possible file formats (mesh, mesh2, pcm)
>
> that's a mesh level problem, not particular to the tesselation patch.
> You want file I/O for mesh, and there was already a macro/include file
> to do that (based on Warp extension to access the mesh structure from SDL).
I forgot there were already hooks for that in Warp's patch, it will be
slower of course, but it would fulfill the purpose.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 22 Feb 2002 12:33:51 +0100, J�r�me Grimbert
<jer### [at] atosorigincom> wrote:
> And soon, you will want a full dump of all Pov-scene...
Fortunatelly it's not a problem, File->Save works fine ;-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The questions were:
%}
%}would you expect the textures of the tesselated object to be taken in the generated
mesh ?
%}Or would you only expect to get the form with only the default texture ?
%}Or something else ?
%}
%}Should the actual texture be used?
%}or sampled at the triangle vertex, keeping only a RGB(TF) vector ?
%}
to which the answers were:
From abx### [at] babilonorg:
> all above should be optional. For example: there is no simple way to
> recreate texture of differently colored blob's components, so sampling colors
> (or even all texture components) for vertices should be possible. But when
> complicated iso-stone is tesselated then there is no need to store texture for
> every vertex but whole mesh should inherit texture from mesh.
To which I provide more info and ended up with:
%> That's not really an answer.
%> May be, the intersection test based could get a copy of the texture structure at
%> the intersection,
%> Whereas the ones using insideness might just inherit a texture if explicitely
%> specified by the SDL ?
>
>So do it at least for intersection methids (if I understand your answer
>correctly)
>
From ing### [at] homenl:
%> Or would you only expect to get the form with
%> only the default texture ?
>Yes, as it is not a copy of an object but a new one.
To which abx### [at] babilonorg objects with:
#>IIRC every object in POV (except mesh and parametric) is new one becouse has
#>own memory representation. Why not to allow optional behaviour ? In case of
#>tesselated blob it could be very difficoult to recreate texture for mesh.
From chr### [at] maccom:
> I don't see a reason for an object rendered using tesselation to have a
> different texture. I'm assuming tesselation is done as an object option
> though, not as generating a new object.
To which tor### [at] onlineno objects with:
#>I think that it would be a great pity if a POV-patch were to perform tessellation
#>of an object without providing the possibility to texture different copies of it
#>differently.
And chr### [at] maccom answered with:
> I wasn't talking about copies, but an alternate rendering method. A
> "tesselate" flag that would cause the object to be tesselated and
> rendered (and traced) as a mesh. Copies would be textured the same way
> any other object copies are textured.
Offtopic:
=========
chr### [at] gmxde provide URL to papers describing adaptative tesselation methods
usable for tesselation of isofunction, blobs and/or parametrics.
I dismissed the paper because my goal is to be able to tesselate ANY solid finite
bounded object (including CSG !), but the papers might be useful to people seeking to
play with isofunction, blobs or parametrics.
Dismissed:
==========
*UV-mapping, for two reasons:
1. There is no generic way to correctly UV-map ANY closed mesh that I know of.
2. I personally never liked UV-mapping. I can appreciate the texture_list in 3.5 for
triangle, and the interpolation it make, but UV-mapping is, for me, breaking one of
the great paradigm of Pov: the immersion of the 3D-object in the 3D procedural
texture, independently of the object. The mapping of 2D texture depending on the 3D
object is still underdevelopped in Pov (slope pattern ?).
*Color-Inheritance because:
1. How to get the texture ? only getting an intersection *might* return an object,
and this object may or not have a texture.
2. The cited example was blob texture, and the computation is done in a special
functions in lighting.c, so sampling this kind of texture would be nearly impossible.
Better to use a texture which use the original blob as the pattern...
Well, may be, just getting the texture from the object returned in the intersection
should be done. There would lake some textures in some case of nexted CSG, but if one
really wants to inherit textures, one should provided a CSG textured at the deepest
level.
Not quite sure yet....
*Tesselate flag, with object specific method for tesselation, because:
1. I do not want to turn Povray in a triangle rendering engine.
2. It involves too much changes, including adding a method!
3. it secretly would change the object. If user (scene writer) really want to use a
mesh instead of a real object, it should explicitely request it so. ( for instance,
the tesselated object can not be used any more in a CSG, and there is no way back, so
this is not a small change).
4. some people think that rendering a mesh is quicker than the real object, but the
building of the mesh bounding tree is quite long in some case (even if it's part of
the parsing time, not the rendering time). Therefore, I believe that tesselation is
NOT the universal answer.
Added to the 'todo' list:
====================
1. All mesh-transformations (bend,screw,roll,smooth,displace,select...) should be
conservative in regard to the individual textures of the triangles, and inherit the
global texture as an option. Well, in fact, the conservatisme of individual textures
should also be another option.
2. A new mesh-transformation option which remove all individual textures from a mesh.
(using select with no restriction apply it to a whole mesh without further
transformation, so it's easily done).
3. Revise and unify the syntax, enforce checking (using a full-keyword oriented
syntax, without any positional information).
4. Allow, only for tesselation which are part of a mesh, to put a texture identifier
over all the new triangles which do not have a specific texture already. (thus
creating a mesh full of colour should be easier)
5. Re-incorporate the 'three texture' interpolation for triangles in mesh. (Just in
case color-inheritance be implemented, and because I like that)
6. Find and implement a mesh decimation such that for example a tesselated cube use
the minimal number of triangles. It will have a bad effect if the decimation is
applied before a transformation, but it should reduce the memory consumption. The
individual texture of the triangles must be taken into account.
7. Find and implement a mesh sub-division such that all triangles have a size small
enough. (allowing to have smoother deformation from initially simpler mesh).
8. Find and implement a mesh Delaunay transformation such that all triangles are
'nice'. Beware of texture consistency.
9. Documents and illustrates!
10. Publish the patch;
--
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
