William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

Hi William, and thanks for taking your time to review my POV code !
I don't know how to say THANK YOU !!
I just built a fresh version of POVRay from master, with your patch on top and
simply adding -MB switch fixed the issue ! (though I don't know if that is the
right way to use it...)
Now the spacecraft is correctly rendered !!
I took the freedom to add your patch (it's literaly your commit :
https://build.opensuse.org/package/view_file/home:bosconovic:Apps/povray/Restore-3.6-user-bounding-control.patch?expand
=1)
to my personal build of povray on the OBS
(https://build.opensuse.org/package/show/home:bosconovic:Apps/povray) for
opensuse Tumbleweed. Let me know if that's ok with you :)

For what concern the textures, IDK wether the parse time is normal or not. I
took the textures from the nasa visible earth website, and they were 40k
textures. The truecolor one was 1.8 gb, and the clouds one was 1 gb, the parse
time was insane, for this reason I resized them to 20k and compressed them using
jpeg algorithm with GIMP.

Again, thank you ! For sure you and the whole newsgroup will have a spot into my
master thesis acknowledgements :)

Post a reply to this message