POV-Ray : Newsgroups : povray.general : Strange cuts on rendered objects : Re: Strange cuts on rendered objects Server Time
27 Apr 2024 13:51:59 EDT (-0400)
  Re: Strange cuts on rendered objects  
From: Alain Martel
Date: 4 Feb 2020 14:40:43
Message: <5e39c8bb@news.povray.org>
Le 2020-02-04 à 09:04, William F Pokorny a écrit :
> On 2/3/20 10:30 AM, Francescodario Cuzzocrea wrote:
>>
>> Hello !!
>>
> ...
>>
>> Can anyone help me out to understand what I'm doing wrong ?
>> Here is the POV source I'm using along with the Blender model :
>> https://gitlab.com/bosconovic/spacacecraft-pov
>>
> ...
>>
> 
> Hi. It looks like there is a bounding problem. My up front bet is it has 
> something to do with the large scale of your scene, but debug work would 
> have to be done to be certain. I can see it's bounding because I have a 
> branch of master (v3.8):
> 
> https://github.com/wfpokorny/povray/tree/fix/restore36UserBoundingControl
> 
> which restores the v3.6 ability to 'truly' turn off all bounding and it 
> is merged into my personal version of povray(1).
> 
> Anyway! A -mb work around hides the fact there is a bounding issue, but 
> given you have not many shapes and that meshes have their own 'shape' 
> bounding running with no bounding would likely work for you.
> 
> I'm occupied with other things at the moment, but a shot in the dark 
> might be to specify a bounded_by object for the satellite mesh as a box 
> or sphere much larger than is determined from the mesh automatically. 
> You would need to keep user bounding on (is it -ur or +ur...? the 
> default these days strips 'most' user specified bounding). Getting 
> ridiculously large user bounding going perhaps another way to work 
> around the actual bounding issue for now.
> 
> If you cannot figure out how to do all yourself, hopefully others can 
> assist you with determining the automatic bounds currently set and flags 
> or options to try this. Of late only checking in here once and a while.
> 
> Aside 2: Those tif files are really slow to parse... Surprised me. 
> Though I don't often work with large image files for textures maybe this 
> speed is normal?
> 
> Bill P.
> 
> (1) Release 3.7 intentionally - or perhaps not - changed code so 
> specifying -mb or +mb<count>, with a count so high bounding does not get 
> used, doesn't always turn off the last level bounding checks.
> 
> I noticed years back because -mb is a useful way to get the bounding out 
> of the way and just check the shape/solver's returned roots. However, 
> the pull request I submitted to fix this was never picked up and after 
> sitting for years I closed it out. Long winded way to say -mb would be a 
> work around for you - except the only way for you to use it would be to 
> compile my branch - or duplicate the changes in a compile of your own.

If that's the case, then, fudging the scale is the way to go :

DO NOT change the scale of the ships. Keep the camera the same relative 
to the ship.
Divide all other distances by 1000 or more.
Also, divide the scale of the planets by 1000.
Make the Sun 1000 times smaller and add the parallel attribute to the 
associated light_source and set the point_at at the ship's location.

parallel is used to simulate a light that is located at infinity.

That should solve the bounding issue.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.