POV-Ray : Newsgroups : povray.general : Strange cuts on rendered objects Server Time
28 Mar 2024 05:18:53 EDT (-0400)
  Strange cuts on rendered objects (Message 9 to 18 of 18)  
<<< Previous 8 Messages Goto Initial 10 Messages
From: Francescodario Cuzzocrea
Subject: Re: Strange cuts on rendered objects
Date: 4 Feb 2020 06:05:01
Message: <web.5e394f816f77a7a5c30604810@news.povray.org>
Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 2/4/20 3:55 AM, also sprach Francescodario Cuzzocrea:
>
> >
> > Hi Alain, and thanks for your reply !
> > Thank for the union tip ! I was using union with split_union off before
> > (otherwhise the object was splitted up in unpredictable way when
> > rotated/translated), then I discovered merge and decided to go for it as it
> > seemed more appropriate, but effectively using union rendering times are a bit
> > faster :)
> >
> >
> >
>
> Did the union fix the problem?  (I liked this idea. I ran into a similar
> issue where I thought merge was more appropriate for cutting my
> mono-colored object, but it had glitches that were solved by using union
> instead.)
>
> --
> dik
> Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

Unfortunately no :( either using union or merge results in the same glitch :(


Post a reply to this message

From: William F Pokorny
Subject: Re: Strange cuts on rendered objects
Date: 4 Feb 2020 09:04:31
Message: <5e3979ef$1@news.povray.org>
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.


Post a reply to this message

From: Francescodario Cuzzocrea
Subject: Re: Strange cuts on rendered objects
Date: 4 Feb 2020 09:55:00
Message: <web.5e39850b6f77a7a5c30604810@news.povray.org>
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

From: Alain Martel
Subject: Re: Strange cuts on rendered objects
Date: 4 Feb 2020 14:33:38
Message: <5e39c712@news.povray.org>
Le 2020-02-04 à 03:55, Francescodario Cuzzocrea a écrit :

> 
> Hi Alain, and thanks for your reply !
> Thank for the union tip ! I was using union with split_union off before
> (otherwhise the object was splitted up in unpredictable way when
> rotated/translated), then I discovered merge and decided to go for it as it
> seemed more appropriate, but effectively using union rendering times are a bit
> faster :)
> 
> 
> 

If you have something like :

#declare Ship = union{
	object{...}
	object{...}
	object{...}
	object{...}
	object{...}
	object{...}
}

Then use :
object{Ship rotate SomeRotation translate Somewhere}

The whole object will be rotated and translated as a single unit.
If not, then, something is wrong in that object's definition.

If you have this :
#declare Ship = union{
	object{...}
	object{...}
	object{...}
	object{...}
	object{...}
	object{...}
rotate SomeRotation
}

The object will also get rotated as a single unit.

BUT, this will cause only part of it to be rotated :
#declare Ship = union{
	object{...}
	object{...}
	object{...}
rotate SomeRotation
	object{...}
	object{...}
	object{...}
}
The part before the rotate will be rotated, but the part after won't.

Maybe there was some stray rotation or translate lost in the object's 
definition.


Post a reply to this message

From: Alain Martel
Subject: Re: Strange cuts on rendered objects
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

From: Francescodario Cuzzocrea
Subject: Re: Strange cuts on rendered objects
Date: 4 Feb 2020 16:05:00
Message: <web.5e39dc476f77a7a5de8751670@news.povray.org>
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

From: Pekka Aho
Subject: Re: Strange cuts on rendered objects
Date: 5 Feb 2020 05:50:00
Message: <web.5e3a9d246f77a7a5d0cd70100@news.povray.org>
A random thought perhaps not even that important for now, but just in case. I
don't know at all how the POV add-on for Blender works, but at least for me
PoseRay has always worked miracles when converting eg. .obj files to mesh2. Some
other utilities may sometimes produce .pov/.inc files that need quite a bit of
tidying up, but PoseRay does it very little for me, if at all. So just a one
more way to diminish possible extra things & weirdnesses ending up in the
scene/code, especially if POV itself is still under learning. :)

https://sites.google.com/site/poseray/


Post a reply to this message

From: Francescodario Cuzzocrea
Subject: Re: Strange cuts on rendered objects
Date: 6 Feb 2020 03:55:00
Message: <web.5e3bd3716f77a7a5c30604810@news.povray.org>
"Pekka Aho" <pek### [at] gmailcom> wrote:
> A random thought perhaps not even that important for now, but just in case. I
> don't know at all how the POV add-on for Blender works, but at least for me
> PoseRay has always worked miracles when converting eg. .obj files to mesh2. Some
> other utilities may sometimes produce .pov/.inc files that need quite a bit of
> tidying up, but PoseRay does it very little for me, if at all. So just a one
> more way to diminish possible extra things & weirdnesses ending up in the
> scene/code, especially if POV itself is still under learning. :)
>
> https://sites.google.com/site/poseray/

Thanks !!
I'll take a look, but I have to run it under Wine as I'm a Linux user. Too bad
that source code isn't available to port it for Linux :(


Post a reply to this message

From: Bald Eagle
Subject: Re: Strange cuts on rendered objects
Date: 6 Feb 2020 08:20:01
Message: <web.5e3c11ac6f77a7a54eec112d0@news.povray.org>
"Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:

> Thanks !!
> I'll take a look, but I have to run it under Wine as I'm a Linux user. Too bad
> that source code isn't available to port it for Linux :(

Same here.   I dumped Windo$e a while back for Mint.
But as Pekka said, PoseRay is excellent.

I suppose in addition to WINE, there are other options - none of which really
look attractive to me.

https://www.codeweavers.com/products/crossover-linux/features
https://www.techlila.com/run-windows-apps-on-linux/


Glad to see your scene is working out better for you.   All the best with your
thesis work!  :)


Post a reply to this message

From: Thomas de Groot
Subject: Re: Strange cuts on rendered objects
Date: 7 Feb 2020 02:26:18
Message: <5e3d111a$1@news.povray.org>
Op 06/02/2020 om 14:16 schreef Bald Eagle:
> 
> "Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:
> 
>> Thanks !!
>> I'll take a look, but I have to run it under Wine as I'm a Linux user. Too bad
>> that source code isn't available to port it for Linux :(
> 
> Same here.   I dumped Windo$e a while back for Mint.
> But as Pekka said, PoseRay is excellent.
> 

Ohum... However, Poseray works under Linux using Wine. See: 
https://sites.google.com/view/poseray and read in the Manual, the 
Install section.


-- 
Thomas


Post a reply to this message

<<< Previous 8 Messages Goto Initial 10 Messages

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