|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, that's true, but if I knew what the object was...
>
> But I have NO idea at this point.
What do you want to say? If you know which object is concerned, you must
declared it and use the name with min_extent.
If you don't know which object, I suggest you to try all the object one
by one. Use comments in your code.
--
Do not judge my words, judge my actions.
---
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm trying to hunt down the origin of an unexpected black box in a scene.
>
> Is there something like Trace() that I can use to find out where the
> object in question is defined? I don't care if there are 7 different
> objects overlapping, at least I'd know which 7 to look into...
>
You may have a box, or any object, that don't have any pigment. To check
for that case, near the begining of your scene, add:
#default{pigment{rgb<1,1,0>}finish{ambient 1}}
If you now have a bright magenta box, you know that you have an object
that don't have any pigment.
It may be caused by overlaping transparent objects. Try adding:
max_trace_level 200
to your global_settings section.
Do you have any iso_surface?
If max_gradiant is to low, you can get some dark or black blocks.
In that case, slightly moving the camera can yeld to large differences
in the result. Move the camera lateraly or verticaly by 1 unit. If the
black box change location/shape, it may be your problem.
If all else fails, put your objects, on at the time, into temporary
unions. That union will contain some marker, like a green sphere set to
ambient 1 or a text object showing some specific text. Make sure that
this added object have a high ambient value.
During debugging, make use of the +qn options to accelerate the
rendering. +q0 will only use pigments with full ambient lighting,
ignoring all lights and finish items. Other values will progressively
enable more features, starting with lights ignoring the area_light
feature. The default for that switch is +q9.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You may have a box, or any object, that don't have any pigment. To check
> for that case, near the begining of your scene, add:
Indeed, that was what I was thinking. However, it seems to be yet
another unexpected behaviour of my door macro. When I comment out the
object {macro} statement, the box disappears. When I run the macro,
which runs flawlessly in a short object development scene which calls
the macro from the include file, it works flawlessly, in all 4 rotations
(front view, left and right views, top view).
But of course, when I run it in my large scene, not only do I get this
mystery black box showing up, but one of my doors is ... _gone_.
I'm getting ready to just start rewriting everything in one large scene
file.
> #default{pigment{rgb<1,1,0>}finish{ambient 1}}
>
> If you now have a bright magenta box, you know that you have an object
> that don't have any pigment.
That's a good debugging technique. I'll add that to my bag of tricks.
Thanks!
> It may be caused by overlaping transparent objects. Try adding:
>
> max_trace_level 200
No, it's not that. It's a box that rotate 90 degrees and sticking back
from the edge of my doorway.
No isosurfaces.
> During debugging, make use of the +qn options to accelerate the
> rendering.
Yes, I've played with that before. So, I just got to Render - Edit
Settings / Render in the Windoze menu, and just add +q[n] to the command
line options...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> #default{pigment{rgb<1,1,0>}finish{ambient 1}}
>>
>> If you now have a bright magenta box, you know that you have an object
>> that don't have any pigment.
That makes the box bright Yellow.
And jacks up the ambient value of everything in the scene. Whoa.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
>...However, it seems to be yet
> another unexpected behaviour of my door macro. When I comment out the
> object {macro} statement, the box disappears. When I run the macro,
> which runs flawlessly in a short object development scene which calls
> the macro from the include file, it works flawlessly, in all 4 rotations
> (front view, left and right views, top view).
> But of course, when I run it in my large scene, not only do I get this
> mystery black box showing up, but one of my doors is ... _gone_.
>
By any chance are you using an orthographic camera for these scenes? In the past
(v3.61, if I recall correctly), I also ran into situations where an object would
suddenly just disappear. It had something to do with how close the ortho camera
was to the object. Moving the camera farther away solved it. I haven't seen that
behavior in awhile...but who knows?
For the black-box mystery, I would suggest (as others have) that you should
comment-out *large* sections of your main scene, to try and whittle down where
the problem might be. But leave your door macro/object intact in the scene, and
try and see when (or if!) the black box disappears. From all that you've posted
so far (and in your previous post), it *seems* that your macro is working
correctly, in and of itself. I'm betting that the problem lies elsewhere. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bald Eagle <cre### [at] netscapenet> wrote:
> >> #default{pigment{rgb<1,1,0>}finish{ambient 1}}
> >>
> >> If you now have a bright magenta box, you know that you have an object
> >> that don't have any pigment.
>
> That makes the box bright Yellow.
> And jacks up the ambient value of everything in the scene. Whoa.
If you're using 'quality 0' to test the scene, then all ambient values will
indeed appear to be maxed out (regardless of using the #default stuff.) Maybe
that's what's visually confusing. Quality 0 adds no color shading or lights-- or
much of *anything* except the full rgb color of the objects.
Also, the #default{pigment{rgb<1,1,0>}finish{ambient 1}} will *only* be imposed
on objects that do not already have an explicitly-stated pigment and finish. In
other words, it will not change anything in the following example:
box{
texture{pigment{rgb <.5,.3,.1>}finish{ambient .3 diffuse .7}}
}
although it might change the FINISH in this example (I'm actually not sure,
without trying it myself)...
box{
texture{pigment{rgb <.5,.3,.1>}} // no explicit finish here
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm trying to hunt down the origin of an unexpected black box in a scene.
>>
>> Is there something like Trace() that I can use to find out where the
>> object in question is defined? I don't care if there are 7 different
>> objects overlapping, at least I'd know which 7 to look into...
>>
>
> You can use min_extent and max_extent which give the coordinates of the
> bounding limits of the object. Use debug to display the values.
>
> #declare Min = min_extent (Obj);
> #declare Max = max_extent (Obj);
>
> #debug concat("[X0=",str(Min.x,1,0),"][X1=",str(Max.x,1,0)"]\n")
> #debug concat("[Y0=",str(Min.y,1,0),"][Y1=",str(Max.y,1,0)"]\n")
> #debug concat("[Z0=",str(Min.z,1,0),"][Z1=",str(Max.z,1,0)"]\n")
>
> In hope this helps you.
> Lionel.
>
Oops! I think I misunderstood the problem!
Can we have some code to see what happens?
Lionel.
--
Do not judge my words, judge my actions.
---
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks, Kenneth,
I didn't change the +q[n] setting.
I just added the default directive and then commented it back out.
maybe
#default {pigment {rgb <1,1,0>} finish {ambient 1} }
needs to be
#default {texture {pigment {rgb <1,1,0>} finish {ambient 1} } }
?
I don't have any orthographic cameras in my scene... yet.
I would however like to see if I could do a smooth transition from an
orthographic camera to a regular perspective camera, and the camera
definitions and behaviours are beyond my ken at this stage of the game.
Once I get the bulk of what I want defined in my scene, then I'll
probably start doing camera experiments and learning some nice animation
skills.
I'll see what I can do with the scene SDL - it's only about 2000 lines
so far, scene, subscene, and include file all together.
I have to rotate and translate my whole subscene to where I want it.
Do you have any clever suggestions for calculating where things should
actually be in my final scene if I copy and paste it all into the big
scene and then correct the coordinates? I'm thinking spreadsheet...
Thanks for all your help,
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bald Eagle <cre### [at] netscapenet> wrote:
>
> maybe
> #default {pigment {rgb <1,1,0>} finish {ambient 1} }
> needs to be
> #default {texture {pigment {rgb <1,1,0>} finish {ambient 1} } }
> ?
Nope, not really necessary. For example, you could, if you wanted to, simply
write...
#default{finish{ambient .5 diffuse .5}}
....which would attach only a *finish* to an object (one that doesn't already
have an explicitly-stated finish, that is.) The 'texture' wrapper isn't
mandatory in a #default statement. In fact, it's not mandatory in an OBJECT
either-- but it's 'good coding practice' to do so, in my opinion... especially
if you decide to add *multiple* overlaid textures to an object; otherwise,
you'll get error messages. To be honest, I rarely use #default{...} in my
scenes; just a personal preference. I like to add full textures to my objects as
I build them. But for quickly creating the basics of a scene-- without worrying
about textures just yet-- #default is certainly useful.
By the way: I hope I didn't confuse you further with my quick-and-dirty
example...
box{
texture{pigment{rgb <.5,.3,.1>}finish{ambient .3 diffuse .7}}
}
The box needs a size, of course-- like box{<0,0,0>,<1,1,1>...
> Do you have any clever suggestions for calculating where things should
> actually be in my final scene if I copy and paste it all into the big
> scene and then correct the coordinates? I'm thinking spreadsheet...
>
Without seeing your code, that would be difficult. My suggestion: Experiment!
It's the best way to find out how things work in POV-Ray; even making mistakes
is beneficial! As the saying goes, "Rome wasn't built in a day!" ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Bald Eagle <cre### [at] netscapenet> wrote:
>>>> #default{pigment{rgb<1,1,0>}finish{ambient 1}}
>>>>
>>>> If you now have a bright magenta box, you know that you have an object
>>>> that don't have any pigment.
>>
>> That makes the box bright Yellow.
>> And jacks up the ambient value of everything in the scene. Whoa.
>
> If you're using 'quality 0' to test the scene, then all ambient values will
> indeed appear to be maxed out (regardless of using the #default stuff.) Maybe
> that's what's visually confusing. Quality 0 adds no color shading or lights-- or
> much of *anything* except the full rgb color of the objects.
>
> Also, the #default{pigment{rgb<1,1,0>}finish{ambient 1}} will *only* be imposed
> on objects that do not already have an explicitly-stated pigment and finish. In
> other words, it will not change anything in the following example:
>
> box{
> texture{pigment{rgb <.5,.3,.1>}finish{ambient .3 diffuse .7}}
> }
>
> although it might change the FINISH in this example (I'm actually not sure,
> without trying it myself)...
>
> box{
> texture{pigment{rgb <.5,.3,.1>}} // no explicit finish here
> }
>
>
For any texture that don't set a finish, or when you use only a pigment,
you get to use the default finish. Also, if your finish don't
explicitely set some finish parameter, the corresponding parameter from
the default will be used.
So, if you have #default{finish{ambient 1}}, any texture or plain
pigment will use ambient 1.
Another somwhat core complex example:
#defaut texture{pigment{rgb<1,0,1>}finish{ambient 0 emission 0.2 diffuse
albedo 0.7 brilliance 2 reflection{1 fresnel} specular albedo 0.7
roughness 0.1}}
This finish will be used UNLESS you explicitely set it to something
else, AND any finish parameter that is not explicitely set will use
those set in the #default directive.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|