Alain Martel <kua### [at] videotronca> wrote:
> 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.

Thanks for your reply !!

I'll try your solution as well tomorrow morning !

Post a reply to this message