On 17-8-2017 13:28, Sven Littkowski wrote:

> I remember now: the resulting meshes in POV-Ray were full of
> distortions, insane spikes. STL2POV is not a good solution.
> 
Hmmm... either that or (1) the stl files are corrupt or (2) normals are 
/not/ consistently outward oriented. I recognise those spikes when 
working on a badly modelled object in Silo.

Thomas

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.08.2017 um 01:12 schrieb Mr:
>
> > Hi, Reading this made me add a few of Lanuhum's properties among which the
> > "hollow" keyword option to objects properties interface, otherwise objects are
> > solid or as much as pov does it.
>
> Does that option directly correspond to POV-Ray's `hollow on` object
> modifier, or does it do something different?
>
The same yes

> > The inside_vector wasn't supported yet but
> > maybe we could add it using the object's origin. that way, if people want a
> > specific inside vector they can just mov object's origin knowing that its
> > coordinates will be used for inside vector?
>
> The `inside_vector` parameter is /not/ a location, but a direction,
> serving a rather technical purpose.
>
> The background is that in order to test whether a point P is inside a
> mesh or not, POV-Ray shoots a ray in the direction specified by
> `inside_vector`, and counts the number of intersections with the mesh.
> If it finds an odd number of intersections in that direction, P is
> considered inside, otherwise it is considered outside.

Indeed I realised this and first thought about using the object center's
orientation, but this could have led to too many problems when animating...
therefore I chose another solution: a simple interface xyz field where to fill
in numbers of the vector this will appear only when a boolean modifier is on,
which I intend to use as interface to CSG

To Sven, do not get scared in believing you need to "learn Blender", actually
three steps after opening the software are enough to create a pov file with it,
They are explained here:
https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/POV-Ray#Quick_Start

In your case, you need to add the extra steps below:
*4 right click default cube to select it hit SUPPR and Enter to delete it
*5 going to the menu File > Import > STL, pick your original data.
*6 uncheck the car icon to deactivate automatic initial options and temporary
file naming, also uncheck the "Delete files" option and check "POV Editor" if
you installed Povwin
*7 fill in a file name and folder

Then just hit F12. and after the first render, Povwin will stay open, you can
just use it to navigate to the pov file of your chosen location.
modify/save/rerender it,

*8 come back here, report any problems

Post a reply to this message

On 18.08.2017 05:16, Mr wrote:
> uncheck the car icon 

8: where is that car icon? I searched the GUI, and also the top menus.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

On 17.08.2017 08:29, Stephen wrote:
> Actually I might download one of the Martian landscapes (Sven, which one
> are you using?) and see what I can do. 

https://nasa3d.arc.nasa.gov/models

Contents of folder "C:\Documents\My 3D\STL\Space":
AsteroidVestaWhole.stl
MarsGaleCrater-209kmAcross.stl
MarsGaleCrater-3xV.stl
MarsPahrumpHills1.obj
MarsPahrumpHills2.obj
MarsTharsisRegion6xv.stl
MarsVallesMarineris1.stl
MarsVallesMarineris2.stl
MarsVallesMarineris3.stl
MoonAristarchusRegion3xV.stl
MoonCopernicusCrater3xV.stl
MoonFarSide.stl
MoonGassendiCrater3xV.stl
MoonNearSide.stl

Yes, I encourage you to download those files. And if you like, I invite
you and everyone else here to join me and to sit seriously together to
make concepts for different types of Moon and Mars bases: which parts
can be underground, and which parts have to remain on the surface, what
materials to be used, what areas the bases would consist of, energy
sources, food sources, and all that. Even texture development.



---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

OK. I think I got an easy and safe method for you to follow:

1) If you do not have it already, download Meshlab 
(http://www.meshlab.net/) and install it.

2) open Meshlab and load the stl mesh.

3) Open 'Export Mesh As...' and export the mesh as an obj file.

4) Open Poseray and load the obj mesh.

5) Go to the 'Groups' folder and press 'Recalculate normals'.

6) Go to the 'POV-Ray Output' folder and export the mesh to POV-Ray 
(results in a mesh2 include file).

-- 
Thomas

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:

> > But the information that I need to do that is:
> > POV-ray shoots a ray in the direction specified by `inside_vector` _FROM_ ---
> > where?
>
> That's something I've wondered about as well.

I did a wee bit more digging, and I found this from the megapov docs:

"To determine if a point is inside a triangle mesh, POV-Ray shoots a ray from
the point in some arbitrary direction (the default is <1, 0, 0>). If this vector
intersects an odd number of triangles, the point is inside the mesh. If it
intersects an even number of triangles, the point is outside of the mesh. You
can specify the direction of this vector. For example, to use +z as the
direction, you would add the following line to the triangle mesh description
(following all other mesh data, but before the object modifiers)."

So it's taking a point that it needs to know whether it's inside or outside the
mesh, and shooting a ray from that point in the direction of the vector you
supply.  So there ARE multiple points - all of the points being tested.

My guess is that the vector can be supplied as a 'tweak' to override the default
value in case there are any weird artefacts showing up due to the cases I
mentioned before.  Skootch the vector a little one way or the other, or give it
a good 30-6-90 degree twist, and you may get a vastly better rendering.

Post a reply to this message

Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
> On 18.08.2017 05:16, Mr wrote:
> > uncheck the car icon
>
> 8: where is that car icon? I searched the GUI, and also the top menus.
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com

Unchecking OS Tempfiles in export settings of older versions, was similar to
unchecking the car icon, in most recent downloads of the script :

https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/POV-Ray#Download

Post a reply to this message

On 18.08.2017 07:16, Thomas de Groot wrote:
> OK. I think I got an easy and safe method for you to follow:
> 1) If you do not have it already, download Meshlab
> (http://www.meshlab.net/) and install it.
> 2) open Meshlab and load the stl mesh.
> 3) Open 'Export Mesh As...' and export the mesh as an obj file.
> 4) Open Poseray and load the obj mesh.
> 5) Go to the 'Groups' folder and press 'Recalculate normals'.
> 6) Go to the 'POV-Ray Output' folder and export the mesh to POV-Ray
> (results in a mesh2 include file).
> 
YES! Finally I got these objects into the POV-Ray scene language!
This was the first challenge.

For the 2nd challenge, seeing all these many posting here in this
thread, I would prefer to open a new thread here in this group:
"Solidifying a Mesh Object".
There we can look for solutions, how to transfer what is now a mesh,
into a solid object. I believe they need to be solid, in order to create
caves and tunnels through Difference into that body.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Am 17.08.2017 um 21:01 schrieb Kenneth:

>> But the information that I need to do that is:
>> POV-ray shoots a ray in the direction specified by `inside_vector` _FROM_ ---
>> where?
> 
> That's something I've wondered about as well.
> 
> From newsgroup comments years ago, my own understanding about inside_vector is
> currently this (and I could be wrong):
> 
> 1) it isn't used until the mesh is CSG'd with some other object.

More precisely, it is only used in non-`union` CSGs.

> 2) Perhaps the 'shoot-from point' (or from *multiple* points) is actually the
> surface of the other intersecting object.

Exactly that.

As a raytracer, POV-Ray's main schtick to render any objects in the
scene is to compute intersection points between rays (usually
originating at the camera location) and object surfaces.

For geometric primitives, ray-surface intersections are computed via
more or less complicated mathematical formulae.

For `union` CSGs, ray-surface intersections are computed simply by
computing the ray-surface intersections with all child objects.

For all other CSGs, the ray-surface intersection points of all the child
objects are filtered according to whether they are /inside/ sibling objects.

Post a reply to this message

Am 17.08.2017 um 21:18 schrieb Bald Eagle:

> (b) if you only "scan" along that single vector - let's say, starting from any
> point along the other object's bounding box - then how do you handle the case(s)
> where the triangle being tested is perfectly parallel to the ray?
> How many intersection would it be calculated as?

In practice, this should only be a problem when all of the following
conditions come together:

1) The mesh must be in a non-union CSG.
2) The `inside_vector` must be parallel to one of the mesh triangles.
3) That triangle must lie in the same plane as one of the sibling object
surfaces.

If conditions 1) and 2) aren't met, this whole thing is a non-issue for
presumably obvious reasons. If condition 3) isn't met, the set of points
for which the test would become problematic is collapsed into
infinitesimally thin lines where the problematic triangles are projected
onto the sibling object surfaces, and the risk of any ray ever hitting
such a region is rather low.

That said, the described scenario may be one of the motivations (if not
the primary one) for making the `inside_vector` a parameter in the first
place, rather than just using a constant direction and toggling the
mechanism on and off with a boolean parameter.

Post a reply to this message