Hello !!

I'm a Master student in Space Engineering in Politecnico di Milano.

I'm using POVRay for my master thesis project and I was really impressed by
POVRay rendering capabilities.

Specifically, I'm using POVRay to generate images of a spacecraft in random
position into a generic orbit, which subsequently I'll analyze with different
computer vision algorithms to try to recognize the spacecraft into the scene.

The spacecraft has first been modeled with Autodesk Inventor, then it has been
imported into Blender to exploit the POVRay addon for Blender capability to
generate directly generate POV code.

The POV blender code was then manipulated in order to obtain a .inc file
containing the "spececraft" object, which is assembled by the "merge"
(https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/satellite.inc#L158)
of the different spacecraft mesh2 components.
I did the merge in order to be able to simply call the "spacecraft" object in my
pov
file and place it into the scene, with the ability to rotate and translate it by
simply manipulating the object's attitude\position matrix (which is randomly
generated) :
https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.pov#L24 .

The issue is that, sometimes, for certain combination of spacecraft\camera
relative position the spacecraft it is not entirely rendered, and I cannot
understand why.

Here two pictures of the problem :
 - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
 - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png

In the first one almost half of the spacecraft is cutted, in the second on the
left a piece of the solar panel is cutted.

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

This is the command I use to generate the images : povray tango_102.pov +H1200
+W1920

Post a reply to this message

"Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:

> Specifically, I'm using POVRay to generate images of a spacecraft in random
> position into a generic orbit, which subsequently I'll analyze with different
> computer vision algorithms to try to recognize the spacecraft into the scene.

Sounds very cool - what computer vision algorithms are you using?
And welcome to the forum.  :)

> Here two pictures of the problem :
>  - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
>  - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
>
> In the first one almost half of the spacecraft is cutted, in the second on the
> left a piece of the solar panel is cutted.
>
> Can anyone help me out to understand what I'm doing wrong ?

Without seeing the code for your scene --- it could be almost anything.

With that said, if I had to simply guess, I'd say that maybe what you're seeing
is a hard shadow from something, if you have other objects in your scene.
Adding finish {diffuse 0.5} and maybe adding a white sky_sphere to your scene
would help you determine if you're just not reflecting any light from occluded
surfaces.


- Bill

Post a reply to this message

Le 2020-02-03 à 10:30, Francescodario Cuzzocrea a écrit :
> 
> 
> 
> Hello !!
> 
> I'm a Master student in Space Engineering in Politecnico di Milano.
> 
> I'm using POVRay for my master thesis project and I was really impressed by
> POVRay rendering capabilities.
> 
> Specifically, I'm using POVRay to generate images of a spacecraft in random
> position into a generic orbit, which subsequently I'll analyze with different
> computer vision algorithms to try to recognize the spacecraft into the scene.
> 
> The spacecraft has first been modeled with Autodesk Inventor, then it has been
> imported into Blender to exploit the POVRay addon for Blender capability to
> generate directly generate POV code.
> 
> The POV blender code was then manipulated in order to obtain a .inc file
> containing the "spececraft" object, which is assembled by the "merge"
> (https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/satellite.inc#L158)
> of the different spacecraft mesh2 components.
> I did the merge in order to be able to simply call the "spacecraft" object in my
> pov
> file and place it into the scene, with the ability to rotate and translate it by
> simply manipulating the object's attitude\position matrix (which is randomly
> generated) :
> https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.pov#L24 .
> 
> The issue is that, sometimes, for certain combination of spacecraft\camera
> relative position the spacecraft it is not entirely rendered, and I cannot
> understand why.
> 
> Here two pictures of the problem :
>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
> 
> In the first one almost half of the spacecraft is cutted, in the second on the
> left a piece of the solar panel is cutted.
> 
> 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
> 
> This is the command I use to generate the images : povray tango_102.pov +H1200
> +W1920
> 
> 
> 
> 
If you had used an orthographic camera, that would be expected for any 
part that are behind the camera, but your sample files are using the 
default perspective camera.

Using an union instead of a merge is more effecient and render faster. 
The merge is intended for transparent compound objects where internal 
surfaces should not be visible.

In your case
#declare Space_Craft = merge{...}
and
#declare Space_Craft = union{...}

Will give you the exact same end result, but the second will render faster.

Post a reply to this message

Op 03/02/2020 om 19:24 schreef Bald Eagle:
> 
> 
> "Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:
> 
>> Specifically, I'm using POVRay to generate images of a spacecraft in random
>> position into a generic orbit, which subsequently I'll analyze with different
>> computer vision algorithms to try to recognize the spacecraft into the scene.
> 
> Sounds very cool - what computer vision algorithms are you using?
> And welcome to the forum.  :)
> 
>> Here two pictures of the problem :
>>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
>>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
>>
>> In the first one almost half of the spacecraft is cutted, in the second on the
>> left a piece of the solar panel is cutted.
>>
>> Can anyone help me out to understand what I'm doing wrong ?
> 
> Without seeing the code for your scene --- it could be almost anything.
> 
> With that said, if I had to simply guess, I'd say that maybe what you're seeing
> is a hard shadow from something, if you have other objects in your scene.
> Adding finish {diffuse 0.5} and maybe adding a white sky_sphere to your scene
> would help you determine if you're just not reflecting any light from occluded
> surfaces.
> 
> 
> - Bill
> 

I tested the scene a bit (not extensively, alas) and I also guess that 
there is a hard shadow, possibly Earth? In tango_102 you translate your 
light_source quite a bit along the x-axis! Does it get partly /behind/ 
the Earth?

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:
>
> > Specifically, I'm using POVRay to generate images of a spacecraft in random
> > position into a generic orbit, which subsequently I'll analyze with different
> > computer vision algorithms to try to recognize the spacecraft into the scene.
>
> Sounds very cool - what computer vision algorithms are you using?
> And welcome to the forum.  :)
>
> > Here two pictures of the problem :
> >  - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
> >  - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
> >
> > In the first one almost half of the spacecraft is cutted, in the second on the
> > left a piece of the solar panel is cutted.
> >
> > Can anyone help me out to understand what I'm doing wrong ?
>
> Without seeing the code for your scene --- it could be almost anything.
>
> With that said, if I had to simply guess, I'd say that maybe what you're seeing
> is a hard shadow from something, if you have other objects in your scene.
> Adding finish {diffuse 0.5} and maybe adding a white sky_sphere to your scene
> would help you determine if you're just not reflecting any light from occluded
> surfaces.
>
>
> - Bill

Hi Bill, thanks for your reply !
I posted the sources at the end of the post, btw here is again the link :
https://gitlab.com/bosconovic/spacacecraft-pov/ :)

Sadly neither adding the sky sphere, nor the finish {diffuse 0.5} did the trick
for my scene :(

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-02-03 à 10:30, Francescodario Cuzzocrea a écrit :
> >
> >
> >
> > Hello !!
> >
> > I'm a Master student in Space Engineering in Politecnico di Milano.
> >
> > I'm using POVRay for my master thesis project and I was really impressed by
> > POVRay rendering capabilities.
> >
> > Specifically, I'm using POVRay to generate images of a spacecraft in random
> > position into a generic orbit, which subsequently I'll analyze with different
> > computer vision algorithms to try to recognize the spacecraft into the scene.
> >
> > The spacecraft has first been modeled with Autodesk Inventor, then it has been
> > imported into Blender to exploit the POVRay addon for Blender capability to
> > generate directly generate POV code.
> >
> > The POV blender code was then manipulated in order to obtain a .inc file
> > containing the "spececraft" object, which is assembled by the "merge"
> > (https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/satellite.inc#L158)
> > of the different spacecraft mesh2 components.
> > I did the merge in order to be able to simply call the "spacecraft" object in my
> > pov
> > file and place it into the scene, with the ability to rotate and translate it by
> > simply manipulating the object's attitude\position matrix (which is randomly
> > generated) :
> > https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.pov#L24 .
> >
> > The issue is that, sometimes, for certain combination of spacecraft\camera
> > relative position the spacecraft it is not entirely rendered, and I cannot
> > understand why.
> >
> > Here two pictures of the problem :
> >   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
> >   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
> >
> > In the first one almost half of the spacecraft is cutted, in the second on the
> > left a piece of the solar panel is cutted.
> >
> > 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
> >
> > This is the command I use to generate the images : povray tango_102.pov +H1200
> > +W1920
> >
> >
> >
> >
> If you had used an orthographic camera, that would be expected for any
> part that are behind the camera, but your sample files are using the
> default perspective camera.
>
> Using an union instead of a merge is more effecient and render faster.
> The merge is intended for transparent compound objects where internal
> surfaces should not be visible.
>
> In your case
> #declare Space_Craft = merge{...}
> and
> #declare Space_Craft = union{...}
>
> Will give you the exact same end result, but the second will render faster.


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 :)

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 03/02/2020 om 19:24 schreef Bald Eagle:
> >
> >
> > "Francescodario Cuzzocrea" <fra### [at] mailpolimiit> wrote:
> >
> >> Specifically, I'm using POVRay to generate images of a spacecraft in random
> >> position into a generic orbit, which subsequently I'll analyze with different
> >> computer vision algorithms to try to recognize the spacecraft into the scene.
> >
> > Sounds very cool - what computer vision algorithms are you using?
> > And welcome to the forum.  :)
> >
> >> Here two pictures of the problem :
> >>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_102.png
> >>   - https://gitlab.com/bosconovic/spacacecraft-pov/blob/master/tango_30.png
> >>
> >> In the first one almost half of the spacecraft is cutted, in the second on the
> >> left a piece of the solar panel is cutted.
> >>
> >> Can anyone help me out to understand what I'm doing wrong ?
> >
> > Without seeing the code for your scene --- it could be almost anything.
> >
> > With that said, if I had to simply guess, I'd say that maybe what you're seeing
> > is a hard shadow from something, if you have other objects in your scene.
> > Adding finish {diffuse 0.5} and maybe adding a white sky_sphere to your scene
> > would help you determine if you're just not reflecting any light from occluded
> > surfaces.
> >
> >
> > - Bill
> >
>
> I tested the scene a bit (not extensively, alas) and I also guess that
> there is a hard shadow, possibly Earth? In tango_102 you translate your
> light_source quite a bit along the x-axis! Does it get partly /behind/
> the Earth?
>
> --
> Thomas

Hi Thomas, thank you for taking your time to poke with my scene !!!

The light source is translated by (more or less) the "true" distance between the
Earth and the Sun.
Said that, I also was guessing that the spacecraft could be partly behind the
Earth before and I tried removing the Earth from the scene as well as nearing
the light source to the object (for istance I putted 1.4723e2) and moving the
light source also along y and z, but none of those worked unfortunately :(

This weird rendering issue was also happening when I was using point lights.
It is very strange because if the object is right front of the camera and the
camera is pointing at the object itself then the object should be rendered in
its entirety :(

Post a reply to this message

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%)

Post a reply to this message

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

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