 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is there a way to override textures or materials that have already been
declared or applied?
I am trying to create a depth map, and need to apply a custom texture to
the entire object.
Thanks.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 8:41 AM, Mike Horvath wrote:
> Is there a way to override textures or materials that have already been
> declared or applied?
>
> I am trying to create a depth map, and need to apply a custom texture to
> the entire object.
>
> Thanks.
>
>
> Mike
Specifying an empty texture
texture {}
to the original object does not seem to do the trick.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.06.2021 um 14:41 schrieb Mike Horvath:
> Is there a way to override textures or materials that have already been
> declared or applied?
>
> I am trying to create a depth map, and need to apply a custom texture to
> the entire object.
If the object in question is a primitive, then I _think_ this should be
possible simply by referencing the object in question and specifying a
new `texture` block, like so:
// original object
#declare OriginalObject = sphere { ... texture { ... } };
// override texture
#declare ClonedObject = object { OriginalObject texture { ... } };
However, if the object in question is a compound object (merge, union or
the like), then I don't think it is possible. At least if the texture is
defined at the component level.
The reason is that the mechanism is designed for use cases in which part
of a compound object's textures are defined while others can be
overridden later. Think e.g. a car, where you can later apply the
texture to use for the car's body, but all the other textures like rims,
tyres, headlights, windscreen etc. are already fixed and immutable.
To achive this, a "texture override" on compound objects only affects
those components that have no explicit texture definition of their own,
while all other components will cling to their textures like superglue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-06-18 à 08:41, Mike Horvath a écrit :
> Is there a way to override textures or materials that have already been
> declared or applied?
>
> I am trying to create a depth map, and need to apply a custom texture to
> the entire object.
>
> Thanks.
>
>
> Mike
In the case of a texture or material that have been declared but not
used yet, a new #declare will completely replace the original with the
new definition.
If it have been applied to something, then redefined, then, any object
that received it will keep the original definition.
In your case, you need to remove, or at least comment out, any texture
or material from your object. Then, apply your new texture to that
object as a whole.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmail com> wrote:
> Is there a way to override textures or materials that have already been
> declared or applied?
What if you union everything together and do an intersection with a box that is
the size of the union's bounding box? The intersection ought to be its own
object that you can give a fresh texture to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 9:30 AM, clipka wrote:
> Am 18.06.2021 um 14:41 schrieb Mike Horvath:
>> Is there a way to override textures or materials that have already
>> been declared or applied?
>>
>> I am trying to create a depth map, and need to apply a custom texture
>> to the entire object.
>
>
> If the object in question is a primitive, then I _think_ this should be
> possible simply by referencing the object in question and specifying a
> new `texture` block, like so:
>
> // original object
> #declare OriginalObject = sphere { ... texture { ... } };
>
> // override texture
> #declare ClonedObject = object { OriginalObject texture { ... } };
>
> However, if the object in question is a compound object (merge, union or
> the like), then I don't think it is possible. At least if the texture is
> defined at the component level.
>
> The reason is that the mechanism is designed for use cases in which part
> of a compound object's textures are defined while others can be
> overridden later. Think e.g. a car, where you can later apply the
> texture to use for the car's body, but all the other textures like rims,
> tyres, headlights, windscreen etc. are already fixed and immutable.
>
> To achive this, a "texture override" on compound objects only affects
> those components that have no explicit texture definition of their own,
> while all other components will cling to their textures like superglue.
It would be nice if I could flag a texture as "important" such that it
overrides all previously defined textures. I can do this in CSS and it
is very handy.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 1:33 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Is there a way to override textures or materials that have already been
>> declared or applied?
>
> What if you union everything together and do an intersection with a box that is
> the size of the union's bounding box? The intersection ought to be its own
> object that you can give a fresh texture to.
>
>
>
Interesting. I will try this.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 10:44 AM, Alain Martel wrote:
> Le 2021-06-18 à 08:41, Mike Horvath a écrit :
>> Is there a way to override textures or materials that have already
>> been declared or applied?
>>
>> I am trying to create a depth map, and need to apply a custom texture
>> to the entire object.
>>
>> Thanks.
>>
>>
>> Mike
>
> In the case of a texture or material that have been declared but not
> used yet, a new #declare will completely replace the original with the
> new definition.
> If it have been applied to something, then redefined, then, any object
> that received it will keep the original definition.
>
> In your case, you need to remove, or at least comment out, any texture
> or material from your object. Then, apply your new texture to that
> object as a whole.
>
Instead of declaring my textures, I may start using macros instead. That
way, I can just comment out the texture declaration inside the macro.
But might this not consume more memory?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
> Is there a way to override textures or materials that have already been
> declared or applied?
>
> I am trying to create a depth map, and need to apply a custom texture to
> the entire object.
>
> Thanks.
>
>
> Mike
Hi Mike,
for depth_maps I use a variable to change every finish ( e.g. finish {specular
dfac*0.3 roughness 0.0003 diffuse dfac*0.6 reflection {dfac*0.03, dfac*0.1}}.
For the "normal" render dfac is defined as 1 and for depthmaps or other
effectmaps dfac is 0.
Together with a white fog you get your depthmap.
Norbert
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.06.2021 um 19:33 schrieb Bald Eagle:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Is there a way to override textures or materials that have already been
>> declared or applied?
>
> What if you union everything together and do an intersection with a box that is
> the size of the union's bounding box? The intersection ought to be its own
> object that you can give a fresh texture to.
That's a smart idea.
You may need to specify `cutaway_textures` though, and I'm not sure
whether it does indeed work with objects that are already explicitly
textured.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> That's a smart idea.
Thanks. This specific issue has been bouncing around in my head for a long
time.
> You may need to specify `cutaway_textures` though, and I'm not sure
> whether it does indeed work with objects that are already explicitly
> textured.
Yes, I figured I'd get into cutaway_textures if there were problems, as I know
it doesn't always work as I expect it to.
The other idea I had was to use either the object texture, or to turn the object
into an isosurface, which should completely scrub any texture information - CSG
or not - since it's an object that gets generated from scratch.
One other option, albeit more challenging, is to generate a mesh from the object
- like Chris Young did with his Christmas ornament for 3D printing, and use the
resulting mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 2:15 PM, Norbert Kern wrote:
> Hi Mike,
>
> for depth_maps I use a variable to change every finish ( e.g. finish {specular
> dfac*0.3 roughness 0.0003 diffuse dfac*0.6 reflection {dfac*0.03, dfac*0.1}}.
> For the "normal" render dfac is defined as 1 and for depthmaps or other
> effectmaps dfac is 0.
> Together with a white fog you get your depthmap.
>
>
> Norbert
>
Could you post some example images? I don't quite understand what this does.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
> Could you post some example images? I don't quite understand what this does.
>
>
> Mike
If you set every diffuse, specular, phong, ambient, emission and reflection
value as zero, you get a black material.
A white fog turns this to an inverse depthmap. Then you can adapt the color_map
of your blurring file or you can invert it via Photoshop and co to get a
"regular" depthmap.
Here is a depthmap of my last image.
Norbert
Post a reply to this message
Attachments:
Download 'mountain_forest_depth.jpg' (285 KB)
Preview of image 'mountain_forest_depth.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2021 um 15:37 schrieb Norbert Kern:
> If you set every diffuse, specular, phong, ambient, emission and reflection
> value as zero, you get a black material.
> A white fog turns this to an inverse depthmap. Then you can adapt the color_map
> of your blurring file or you can invert it via Photoshop and co to get a
> "regular" depthmap.
> Here is a depthmap of my last image.
Some caveats of this approach:
- The brightness will not depend on the Z coordinate, but on the
distance to the camera; this may or may not be what you want.
- The image value will not represent the distance itself, but rather an
exponential-ish function thereof, something like:
f(d) = 1 - p^d
where p is a value < 1. Again, this may or may not be what you want.
Also, like with every other thing where you want to get a per-pixel
value out of the render rather than a color, the topic of gamma needs
attention, and also precision, i.e. bit depth.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-06-18 à 13:52, Mike Horvath a écrit :
> On 6/18/2021 10:44 AM, Alain Martel wrote:
>> Le 2021-06-18 à 08:41, Mike Horvath a écrit :
>>> Is there a way to override textures or materials that have already
>>> been declared or applied?
>>>
>>> I am trying to create a depth map, and need to apply a custom texture
>>> to the entire object.
>>>
>>> Thanks.
>>>
>>>
>>> Mike
>>
>> In the case of a texture or material that have been declared but not
>> used yet, a new #declare will completely replace the original with the
>> new definition.
>> If it have been applied to something, then redefined, then, any object
>> that received it will keep the original definition.
>>
>> In your case, you need to remove, or at least comment out, any texture
>> or material from your object. Then, apply your new texture to that
>> object as a whole.
>>
>
> Instead of declaring my textures, I may start using macros instead. That
> way, I can just comment out the texture declaration inside the macro.
> But might this not consume more memory?
>
>
> Mike
Whenever you use a macro, it get expanded every times it's used, so,
will use more memory while parsing.
When you use a declared texture that is applied in many places, then,
you can change it everywhere at once by changing the declare.
With a macro, you can do the same by changing the definition of the
macro. That won't affect the parameters passed to that macro anywhere in
the scene, but, you can change the macro so that it still accept the
same parameter but ignore them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2021 2:53 PM, clipka wrote:
> Am 18.06.2021 um 19:33 schrieb Bald Eagle:
>> Mike Horvath <mik### [at] gmailcom> wrote:
>>> Is there a way to override textures or materials that have already been
>>> declared or applied?
>>
>> What if you union everything together and do an intersection with a
>> box that is
>> the size of the union's bounding box? The intersection ought to be
>> its own
>> object that you can give a fresh texture to.
>
> That's a smart idea.
>
> You may need to specify `cutaway_textures` though, and I'm not sure
> whether it does indeed work with objects that are already explicitly
> textured.
What is `cutaway_textures`? I have never head of it.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/19/2021 10:38 AM, clipka wrote:
> Am 19.06.2021 um 15:37 schrieb Norbert Kern:
>
>> If you set every diffuse, specular, phong, ambient, emission and
>> reflection
>> value as zero, you get a black material.
>> A white fog turns this to an inverse depthmap. Then you can adapt the
>> color_map
>> of your blurring file or you can invert it via Photoshop and co to get a
>> "regular" depthmap.
>> Here is a depthmap of my last image.
>
> Some caveats of this approach:
>
> - The brightness will not depend on the Z coordinate, but on the
> distance to the camera; this may or may not be what you want.
>
> - The image value will not represent the distance itself, but rather an
> exponential-ish function thereof, something like:
>
> f(d) = 1 - p^d
>
> where p is a value < 1. Again, this may or may not be what you want.
>
>
> Also, like with every other thing where you want to get a per-pixel
> value out of the render rather than a color, the topic of gamma needs
> attention, and also precision, i.e. bit depth.
Would it work better if depth maps were an engine feature versus a bunch
of tricks/hacks with pigments or fog?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/19/2021 3:38 PM, Mike Horvath wrote:
> On 6/19/2021 10:38 AM, clipka wrote:
>> Am 19.06.2021 um 15:37 schrieb Norbert Kern:
>>
>>> If you set every diffuse, specular, phong, ambient, emission and
>>> reflection
>>> value as zero, you get a black material.
>>> A white fog turns this to an inverse depthmap. Then you can adapt the
>>> color_map
>>> of your blurring file or you can invert it via Photoshop and co to get a
>>> "regular" depthmap.
>>> Here is a depthmap of my last image.
>>
>> Some caveats of this approach:
>>
>> - The brightness will not depend on the Z coordinate, but on the
>> distance to the camera; this may or may not be what you want.
>>
>> - The image value will not represent the distance itself, but rather
>> an exponential-ish function thereof, something like:
>>
>> f(d) = 1 - p^d
>>
>> where p is a value < 1. Again, this may or may not be what you want.
>>
>>
>> Also, like with every other thing where you want to get a per-pixel
>> value out of the render rather than a color, the topic of gamma needs
>> attention, and also precision, i.e. bit depth.
>
> Would it work better if depth maps were an engine feature versus a bunch
> of tricks/hacks with pigments or fog?
>
>
> Mike
Not saying you should implement it. 3D photos (see other thread) don't
seem to actually work that well except in a minority of specific cases.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
> What is `cutaway_textures`? I have never head of it.
It's a keyword
http://www.povray.org/documentation/view/3.6.1/362/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is this the same as:
http://news.povray.org/povray.advanced-users/thread/%3C5e52bde0%241%40news.povray.org%3E/
http://news.povray.org/povray.newusers/thread/%3Cweb.5c90a6ab69c1cfb51d791a250%40news.povray.org%3E/
?
I have done a similar thing for 3D printing, and simply used a gradient texture,
scaled and translated to contain the entire scene within the 0-1 range.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2021 um 21:38 schrieb Mike Horvath:
> Would it work better if depth maps were an engine feature versus a bunch
> of tricks/hacks with pigments or fog?
No. It would just be simpler to set up (no tampering with textures,
pigments, fog and/or interiors) while at the same time potentially less
flexible.
(As a matter of fact, if I'm not mistaken older versions of POV-Ray
provided such a feature. At the very least MegaPOV did.)
The caveats I mentioned aren't necessarily problems, just things to be
mindful of, that might require modifications to the process if they
should happen to not exactly be what you need.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> (As a matter of fact, if I'm not mistaken older versions of POV-Ray
> provided such a feature. At the very least MegaPOV did.)
I did come across mention of such a feature, as well as your pointing out how
gamma needs to be considered:
https://news.povray.org/povray.unofficial.patches/thread/%3Cweb.4ab74a31bf54fa92ea2377910%40news.povray.org%3E/?ttop=43
3088&toff=50
> The caveats I mentioned aren't necessarily problems, just things to be
> mindful of, that might require modifications to the process if they
> should happen to not exactly be what you need.
I think that when a somewhat commonly requested solution for a problem like this
gets solved, that's the time for the/a contributor to post a functional scene
file so that it gets added to the pile of stuff we have on the server. Then
it's simply a matter of pointing them to the link, or including such a sample
scene in the next release.
(Some things ought to be added to the engine, since SDL is slow and the code for
such tasks would need to be FAST, and therefore compiled)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 15:37 schrieb Norbert Kern:
>
> > If you set every diffuse, specular, phong, ambient, emission and reflection
> > value as zero, you get a black material.
> > A white fog turns this to an inverse depthmap. Then you can adapt
> > the color_map of your blurring file or you can invert it via Photoshop
> > and co to get a "regular" depthmap.
> > Here is a depthmap of my last image.
< [Clipka:]
> Some caveats of this approach:
> [snip]
Using fog to create a depth-map is a very clever idea, even with the caveats
that Clipka mentions.
From some quick experiments I just did, I've found what may be a simpler fog
method, that does not require any adjustments to a scene's object textures at
all. They can be left as-is.
1) Turn off any LIGHTS in the scene.
2) In the scene's global_settings block, add ambient_light 0.0 -- which is a
multiplier for any ambient light in the objects' finishes.
3) Use a simple fog statement (default fog_type 1) like
fog{rgb 1 distance 15}
..... or whatever distance value looks correct. This will produce a gray-scale
depth_map with pure white in the distant background, and black *at* the camera,
I think. The interesting point about this set-up is that all of the objects'
COLORS seem to be 'eliminated'-- the entire scene is now just gradations of
gray. Apparently, with no actual light in the scene, and no finish{ambient or
emission}, the fog 'color' is the only color seen; all of the object colors are
suppressed.
Perhaps a ground fog (fog_type 2) may be better-suited to this, but modified--
possibly by setting the fog's 'sky' vector to be the same as the camera look_at
vector(?). The idea being that ground fog has more parameters that can be
tweaked, to possibly 'fudge' some of the depth/distance problems that Clipka
mentioned. Just a guess though.
Also, try srgb 1 for the fog color, which should(?) produce a 'different' type
of exponential fog-color falloff. Maybe.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> From some quick experiments I just did, I've found what may be a simpler fog
> method, that does not require any adjustments to a scene's object textures at
> all. They can be left as-is.
>
Well...it was a nice *idea*, but... no good.
Objects' surface finishes like phong/specular, and/or especially reflection,
screw up the gray-scale values imposed by the fog. So all of those need to first
be reduced to zero, as has already been mentioned. And any texture transparency
is also a big problem.
My bad.
----------
It would be useful to have 'global' multipliers for most or all of the various
finish{...} attributes-- similar to the current ambient_light keyword-- to
easily and quickly reduce any of those parameters in a scene to zero if needed.
Like...
emission_light *float value*
reflection_global *float value*
phong_global *float value*
.... etc.
And maybe even one for object transparency! (t and f both)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-06-24 1:09 PM (-4), Kenneth wrote:
>
> Also, try srgb 1 for the fog color, which should(?) produce a 'different' type
> of exponential fog-color falloff. Maybe.
This will not make any difference. POV-Ray has only one type of color,
and the srgb keyword is merely a different way of specifying them.
To change the falloff, try changing assumed_gamma.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-06-24 1:09 PM (-4), Kenneth wrote:
> >
> > Also, try srgb 1 for the fog color, which should(?) produce
> > a 'different' type of exponential fog-color falloff. Maybe.
>
> This will not make any difference. POV-Ray has only one type of color,
> and the srgb keyword is merely a different way of specifying them.
>
Yep, you're right. I just tried it anyway, but no change.
I also thought that render Quality_Level might be a way to suppress the objects'
finish{...} attributes; but fog itself does not 'appear' until Quality_Level 9,
at which point all of the finish stuff is there as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-06-24 à 13:09, Kenneth a écrit :
> Also, try srgb 1 for the fog color, which should(?) produce a 'different' type
> of exponential fog-color falloff. Maybe.
>
srgb 0 is exactly the sama as rgb 0, and srgb 1 exactly the same as rgb 1.
Those are the two intersection points between those two.
The use of srgb have no effect on any fading or gradient.
gradient x colour_map{[0 rgb 0][1 rgb 1]}
will render exactly the same as
gradient x colour_map{[0 srgb 0][1 srgb 1]}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have essentially accomplished the end goal 4+ years ago, when I needed a depth
map for laser-engraving "2D" images in 3D relief.
I simply use the orthographic camera, union everything in the scene, find the
min and max z, normalize that to a 0-1 range, and then trace over every pixel
position of the image in the direction of the "direction" vector.
Then I create a 1 pixel-wide box with an rgb value directly proportional to the
normalized distance to the ray intersection point.
It's maybe 30 lines of code including the #debug statements.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
>
>
> > Also, try srgb 1 for the fog color, which should(?) produce
> > a 'different' type of exponential fog-color falloff. Maybe.
> >
>
> srgb 0 is exactly the sama as rgb 0, and srgb 1 exactly the same as rgb 1.
> Those are the two intersection points between those two.
> The use of srgb have no effect on any fading or gradient.
>
> gradient x colour_map{[0 rgb 0][1 rgb 1]}
> will render exactly the same as
> gradient x colour_map{[0 srgb 0][1 srgb 1]}
Oops! You are correct. Yes, I was thinking of the *possible* change that 'srgb'
might make to the black-to-white fog gradient. But as you say, rgb and srgb look
the same.
I must have been thinking instead about the effects that the newer blend_mode
and blend_gamma keywords have on a color_map. But simple fog cannot use a
color_map, unfortunately.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/19/2021 8:52 PM, clipka wrote:
> Am 19.06.2021 um 21:38 schrieb Mike Horvath:
>
>> Would it work better if depth maps were an engine feature versus a
>> bunch of tricks/hacks with pigments or fog?
>
> No. It would just be simpler to set up (no tampering with textures,
> pigments, fog and/or interiors) while at the same time potentially less
> flexible.
>
> (As a matter of fact, if I'm not mistaken older versions of POV-Ray
> provided such a feature. At the very least MegaPOV did.)
>
>
> The caveats I mentioned aren't necessarily problems, just things to be
> mindful of, that might require modifications to the process if they
> should happen to not exactly be what you need.
Sorry, I don't mean would it "work better". I mean would it "be better",
as in "easier" or "more convenient".
But I no longer am interested in this topic since I will likely not be
making any additional 3D photos in the near future. My use case has its
own separate issues and is not worth pursuing further.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/19/2021 12:58 PM, Alain Martel wrote:
> Whenever you use a macro, it get expanded every times it's used, so,
> will use more memory while parsing.
>
I have 16GB RAM, so it makes no difference in my case. But it seems
wasteful.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
