"circuit" <nomail@nomail> wrote:
I also messed
> around with the radiosity settings according to
> http://wiki.povray.org/content/HowTo:Use_radiosity and the combination seems to
> have done the trick!

Ah yes - Ricky, that was a good catch with the radiosity.   I've seen it before,
but I don't use it often enough, nor as often as I should  ;)


> I seem to have some issues with the rear spindle flashing when the wheel is
> given transparency. How can I prevent this?

It's hard to tell with so few frames, but:
You may be casting a shadow onto that with your 3-armed object.
add no_shadow to whichever part it is
mesh2 {Part39 no_shadow} and see if that fixes it.
or you could add the "shadowless" keyword to your light_source definition and
that won't cast any shadows for anything.
Later, if you want shadows, but don't want THAT shadow, you may have to split
the scene into different "light groups" or something else.

That _looks_ to me like it could be partly the dreaded "coincident surface"
problem.
You need a tiny amount of space (> 0.000001 POV units) between scene elements
otherwise how does the renderer "know" which texture to make the pixel where 2
objects are that occupy the same pixel?  There's some digital/coding/floating
point error that plays into that that needs to be accounted for, thus the 1e-6
value as insurance against it.

I think if you're just adding a transmit value, that should be ok.  If you use
filter instead, then you will get oscillations when the thick and thin parts
move across that back piece.  Twice the thickness = twice the filtering.

Also, for preliminary developmental purposes, you may want to decrease the size
of your renders, say to 640x480 or even 320x240, and then crank up the number of
frames you render to give a much smoother animation.   I'd shoot for at least 15
FPS or above for the final render.


> I'm not sure how to attach files,

The way this whole thing is set up, you need to use one of the sections that
allows attachments.    povray.binaries.images (p.b.i) is the usual spot.
http://news.povray.org/povray.binaries.images/

Typically, the best way to link threads and perhaps shift the discussion over
there is to post the image first, wait for a bit for the server to process the
image, and then go to your post and copy the link and paste it here in your next
post.


It's looking good so far  :)
Are you running windows?
I know that some folks on here are looking for a functioning modeler, as well as
a way to export to .stl for 3D printing, and they may be interested in how to
set up FreeCAD and what its capabilities are.

Post a reply to this message

On 2020-05-09 10:56 PM (-4), circuit wrote:
>  I'm not sure how to attach files, so
> I uploaded one animation frame's .pov content here (I can uploaded all 20 if
> needed):

You appear to be using the Web interface, and the Web interface does not 
allow attachments in povray.newusers.  You can post attachments in 
newsgroups with "binaries" in their name, such as 
povray.binaries.scene-files and povray.binaries.images.  A newsreader 
app can post attachments to any newsgroup, but that is considered bad 
netiquette.

Post a reply to this message

Le 2020-05-09 à 19:59, Bald Eagle a écrit :
> 
> "circuit" <nomail@nomail> wrote:
> 
> Update to #version 3.8 if at all possible.
> 
>>          Antialias_Threshold=0.05
> 
> I truly don't know squat about aa settings, but maybe try 0.3 - which seems
> standard.

That antialias setting is ok for final renders. A good compromise would 
be something like 0.1.

> 
> 
>>              // Standard finish
>>              #declare StdFinish = finish { crand 0.01 diffuse 0.8 };
> 
> Get rid of crand.  _Especially_ if you're doing an animation.
> Diffuse seems a bit high, I might be tempted to add a touch of specular
> (0.1-0.2), but that's inconsequential to your problem.

I agree.

> 
> 
>>              //default light
>>              light_source {
>>                  cam_location
>>                  color White
>>                  area_light <100, 0, 0>, <0, 0, 100>, 10, 10
>>                  adaptive 1
>>                  jitter
>>              }
> 
> That seems - excessive?  Especially for a simple render.
> And it might have something to do with the weird look.
> Just use a standard point light source, and you'll get adequate lighting and
> good shadows.

Yes, should use adaptive 0

> 
> Hard to really say what other potential problems may be without seeing the scene
> as a whole.   You can post .pov files in the scene files section if the above
> doesn't fix anything.
> 
> 
>

Post a reply to this message

Le 2020-05-09 à 20:47, Cousin Ricky a écrit :
> On 2020-05-09 7:43 PM (-4), circuit wrote:
>> Hey all. Just started using POV-Ray with FreeCAD. I'm trying to render 
>> a solid
>> assembly, and so far have had reasonable success. The issue I'm facing 
>> is that
>> the output surface has a lot of imperfections around edges. You can 
>> see what I
>> mean here:
>>
>> https://i.imgur.com/jmSYFlA.png
> 
> Without seeing the whole scene description file, it's hard to say, but 
> the "imperfections" in the image look like radiosity artifacts.  The 
> setting Radiosity_Normal uses:
>    count 200
>    error_bound 0.3
>    pretrace_end 0.01
> 
> Increasing count will always improve radiosity, but tweaking the other 
> settings can often get the job done more efficiently.  A pretrace_end of 
> 0.01 seemed fine for POV-Ray 3.6, which is what the scene file was 
> designed for; but if your POV-Ray installation is 3.7 or later, 0.01 is 
> inadequate.  The rad_def.inc settings were not updated in the 3.7 update.

They where not even updated for version 3.5, only the version directive 
got updated. They are based on early 3.3, or maybe even older.
That include is in desperate need of a complete overhaul.
Before version 3.5, low_error_factor defaulted to 0.8. Starting with 
version 3.5, the default low_error_factor is 0.5. red_def.inc use that 
old 0.8 value as a base.

> 
> These settings are usually good enough in my experience:
>    error_bound 0.5
>    pretrace_end 2 / max (image_width, image_height)
>    recursion_limit 2
> 
> If there are still artifacts, try changing pretrace_end to:
>    pretrace_end 1 / max (image_width, image_height)
> 
> P.S. As long as your scene file starts with #version 3.6; and uses 
> radiosity, all ambients on non-glowing objects should be set to zero. If 
> your objects and textures have ambients individually applied, and none 
> of your objects glow in the dark, this is easily done with 
> global_settings { ambient_light 0 }.  If you do have glowing objects, 
> you cannot change the global ambient_light; you must instead use 
> #default { finish { ambient 0 } }, and delete or override any ambients 
> on non-glowing objects and textures.
> 

With version 3.7 and later, there is no need to set ambient to zero as 
all ambient become zero when radiosity is used.
You need to use emission for glowing objects.

Post a reply to this message

On 2020-05-10 12:18 PM (-4), Alain Martel wrote:
> Le 2020-05-09 à 19:59, Bald Eagle a écrit :
>>
>>>              //default light
>>>              light_source {
>>>                  cam_location
>>>                  color White
>>>                  area_light <100, 0, 0>, <0, 0, 100>, 10, 10
>>>                  adaptive 1
>>>                  jitter
>>>              }
>>
>> That seems - excessive?  Especially for a simple render.
>> And it might have something to do with the weird look.
>> Just use a standard point light source, and you'll get adequate 
>> lighting and
>> good shadows.
> 
> Yes, should use adaptive 0

That depends on the scene.  I've had some scenes for which adaptive 0 
was fine, and others for which the result was hideous.

Post a reply to this message

Wow, this community is awesome. I appreciate all the responses.

> That _looks_ to me like it could be partly the dreaded "coincident surface"
> problem.
> You need a tiny amount of space (> 0.000001 POV units) between scene elements
> otherwise how does the renderer "know" which texture to make the pixel where 2
> objects are that occupy the same pixel?  There's some digital/coding/floating
> point error that plays into that that needs to be accounted for, thus the 1e-6
> value as insurance against it.

100% sure it's a coincident surface issue. In fact, similar artifacting also
exists in FreeCAD's rendered output. Here's an animation using FreeCAD
"activeView":

https://i.imgur.com/zljJarj.gifv

This is actually not my model... it's just the first demo file I found online
that had assembly constraints, so I ran with it. I have no idea if it was
designed properly. I plan on testing this out more thoroughly with a model I
build myself.

> Also, for preliminary developmental purposes, you may want to decrease the size
> of your renders, say to 640x480 or even 320x240, and then crank up the number of
> frames you render to give a much smoother animation.   I'd shoot for at least 15
> FPS or above for the final render.

For sure. Here's a smoother animation! This time at 20 fps:

https://i.imgur.com/6c3mLUn.gifv

It's definitely a lot quicker to render this way. I took me around 2 minutes for
the 50 frames on my i5 laptop.

> It's looking good so far  :)
> Are you running windows?
> I know that some folks on here are looking for a functioning modeler, as well as
> a way to export to .stl for 3D printing, and they may be interested in how to
> set up FreeCAD and what its capabilities are.

I am on Windows, yup, although I've played around with a few Linux distros in
the past :) I'm by no means a modeller though. I come from an electrical
background, but I have a strong interest in robotics. My plan is to use FreeCAD
to design and simulate (animate) robotic gait. Then of course, once I'm happy,
I'll 3D print the end result. POV-Ray just makes the animation quite a bit
nicer.

From my limited exposure, I'm really liking FreeCAD. I've used Fusion 3D and
Solidworks in the past, and sure, FreeCAD is not quite as polished, but it one
really great thing going for it: Python scripting. The possibilities are
limitless. Other than that, FreeCAD seems to be just as capable as the others
(but once again, I'm not a power user).

I'm happy to help provide guidance if other wants to delve into the tool.

> Yes, should use adaptive 0

I like output a lot better with this change. Edges are better defined.

Cheers everyone.

Post a reply to this message

"circuit" <nomail@nomail> wrote:
> Wow, this community is awesome. I appreciate all the responses.

We try.  :)
There's always so much to do, and it's so much easier to get things _done_ when
you can get past all the hurdles.  We all help out as best we can.


> 100% sure it's a coincident surface issue. In fact, similar artifacting also
> exists in FreeCAD's rendered output. Here's an animation using FreeCAD
> "activeView":

Find min_extent and max_extent of all the parts, calculate the centers,
translate to center, scale down by a wee bit, then translate back.
With that many parts, I'd probably write a little macro that takes an object{}
as an argument.

> This is actually not my model... it's just the first demo file I found online
> that had assembly constraints, so I ran with it. I have no idea if it was
> designed properly. I plan on testing this out more thoroughly with a model I
> build myself.

Naturally.  Always a lot easier to get things moving with pre-built stuff.


> I come from an electrical
> background, but I have a strong interest in robotics. My plan is to use FreeCAD
> to design and simulate (animate) robotic gait.

Nice.   Chemist myself, but I dabble with things with my EE friend.
You should look up Rune's spider animation.  Very impressive.

Post a reply to this message

Le 2020-05-10 à 13:09, Cousin Ricky a écrit :
> On 2020-05-10 12:18 PM (-4), Alain Martel wrote:
>> Le 2020-05-09 à 19:59, Bald Eagle a écrit :
>>>
>>>>              //default light
>>>>              light_source {
>>>>                  cam_location
>>>>                  color White
>>>>                  area_light <100, 0, 0>, <0, 0, 100>, 10, 10
>>>>                  adaptive 1
>>>>                  jitter
>>>>              }
>>>
>>> That seems - excessive?  Especially for a simple render.
>>> And it might have something to do with the weird look.
>>> Just use a standard point light source, and you'll get adequate 
>>> lighting and
>>> good shadows.
>>
>> Yes, should use adaptive 0
> 
> That depends on the scene.  I've had some scenes for which adaptive 0 
> was fine, and others for which the result was hideous.
> 

You start with adaptive 0. If it's OK, good for you. Only if there are 
some glitches do you  ever need  to use adaptive 1 or more. You rarely 
ever need to go over adaptive 2.

Just remember at what values adaptive start :
adaptive 0 start with 2x2
adaptive 1 is 3x3
adaptive 2 is 5x5
adaptive 3 is 9x9
adaptive 4 is 17x17

You need to have at least two steps more than the starting value to get 
any notable performance improvement.

Also, that 10x10 get silently upgraded to 17x17.

Post a reply to this message

> I seem to have some issues with the rear spindle flashing when the wheel is
> given transparency. How can I prevent this?

For sure this is due to touching surfaces, so POV-Ray (quasi)randomly picks
which one to render. Should have some tiny amount of distance between parts, and
it will work fine...

Post a reply to this message

> The issue I'm facing is that
> the output surface has a lot of imperfections around edges.

As already well put by other guys, those are radiosity artifacts, and it's pain
to clean them out... there are two parameters that must be balanced, 'count' and
'error_bound'. I will upload image in a separate post to clarify.

Generally, I combat these artifatcs by using:
-textures, image maps - not plain flat surfaces
-complex lightning scene - not single point light or sky dome
-actual environment, room, background - not object suspended in empty black
space
-focal blur - even a subtle amount works miracles
-large renders (5000+ px) - then apply small amount of gauss or other blur
filter

Post a reply to this message