 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
See the thread in povray.general ("Can I bake UV textures with Povray?") for
discussion.
There are very slight differences between the two images which aren't very
noticeable. One difference (and the most significant one) is that along the
corners, the UV mapped version has some slight artifacts because it's
sampling from the background area of the UV texture. This would be more
noticable if I had used a lower resolution UV map (the version shown is half
the size of the original 512x512). The other difference is that there is a
very tiny discrepancy in some triangles between where colors in the
procedural texture appear and where colors in the UV texture appear;
probably due to innacuracies in the sampling.
This would be better implemented as a patch, especially because of how
incredibly slow it is (there may be room for some optimization). But in a
pinch it can do the trick.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
Attachments:
Download 'uvbaking.png' (152 KB)
Preview of image 'uvbaking.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> See the thread in povray.general ("Can I bake UV textures with Povray?") for
> discussion.
>
> There are very slight differences between the two images which aren't very
> noticeable. One difference (and the most significant one) is that along the
> corners, the UV mapped version has some slight artifacts because it's
> sampling from the background area of the UV texture. This would be more
> noticable if I had used a lower resolution UV map (the version shown is half
> the size of the original 512x512). The other difference is that there is a
> very tiny discrepancy in some triangles between where colors in the
> procedural texture appear and where colors in the UV texture appear;
> probably due to innacuracies in the sampling.
>
> This would be better implemented as a patch, especially because of how
> incredibly slow it is (there may be room for some optimization). But in a
> pinch it can do the trick.
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
>
Well I for one am damned impressed! You said the UV projection had to
be established first. How did you do that? The reason I ask is that I
think the polys would have to have be contiguous in some way if the next
stage in the workflow was to take the template and add more stuff, say
hand-drawn wrinkles, for instance. That, anyway, is how I imagine this
technique would play a role in a workflow. I assume by your description
that that could be done. How you get the original UV's is arbitrary right?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well I for one am damned impressed!
Thank you! =)
> You said the UV projection had to
> be established first. How did you do that?
The mesh and UV coordinates were both made with Wings 3D.
> The reason I ask is that I
> think the polys would have to have be contiguous in some way if the next
> stage in the workflow was to take the template and add more stuff, say
> hand-drawn wrinkles, for instance. That, anyway, is how I imagine this
> technique would play a role in a workflow. I assume by your description
> that that could be done. How you get the original UV's is arbitrary
right?
Yup. You can generate the UV coordinates any way you want, just as long as
you can get them into your POV-Ray code.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>>Well I for one am damned impressed!
>
>
> Thank you! =)
>
>
>>You said the UV projection had to
>>be established first. How did you do that?
>
>
> The mesh and UV coordinates were both made with Wings 3D.
>
>
>>The reason I ask is that I
>>think the polys would have to have be contiguous in some way if the next
>>stage in the workflow was to take the template and add more stuff, say
>>hand-drawn wrinkles, for instance. That, anyway, is how I imagine this
>>technique would play a role in a workflow. I assume by your description
>>that that could be done. How you get the original UV's is arbitrary
>
> right?
>
> Yup. You can generate the UV coordinates any way you want, just as long as
> you can get them into your POV-Ray code.
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
This is really significantly useful. People use it to interactively
locate prcedurally generated bits of texture. But beyond that it seems
to me that it practically guarantees that the texture would lay flat and
be appropiately scaled since you are working *back* to the pre-existing
uv projection. This would give us a piece of fuctionality that
characterizes the highend integrated apps. It also seems to me that if
written as a patch, it would be efficious stand alone. Once the uvmap
is gained, processing could be shifted to a different patch for any
other functionality needed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, nice work Slime! This is not going to slip away as a neat knick knack
macro, but should become a permanent addition to POV-Ray.
Skip
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Skip Talbot" <Ski### [at] aol com> schreef in bericht
news:4126f94d$1@news.povray.org...
> Yes, nice work Slime! This is not going to slip away as a neat knick
knack
> macro, but should become a permanent addition to POV-Ray.
>
I fully support that!!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:4126b020@news.povray.org...
> This would be better implemented as a patch, especially because of how
> incredibly slow it is (there may be room for some optimization). But in a
> pinch it can do the trick.
The concept looks great! Note that it requires not only pre-existing UVs but
also a completely unwrapped UV-map. It sure would be nice if someone would
turn it into a patch, both for speed and to avoid the creation of
potentially huge arrays in SDL.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:4126b020@news.povray.org Slime wrote:
> This would be better implemented as a patch, especially because of how
> incredibly slow it is
Nice!
Imagine it in combination with the tesselation patch (or the tri-scan
macro).
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> See the thread in povray.general ("Can I bake UV textures with Povray?")
for
> discussion.
Sorry, I haven't got time to read that thread now, but the useful thing here
would be to bake the result of raytracing / radiosity. This would save an
enourmous amount of rendering time during animation. (in areas where the
light doesn't change).
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
