 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/17/2017 1:00 PM, Bald Eagle wrote:
> I'd stop trying to use Blender if you want to render your scene in POV-Ray ----
> just convert your OBJ or STL to a mesh, and then do all the fine-tuning in
> POV-ray.
>
I think that is probably the best idea.
STL > OBJ > Mesh 2
Blender is an all things to all people program and there is so much to
learn.
> AND, as you know, you can post a (small) mesh and your scene file, and then
> someone can edit it to get it to work.
Actually I might download one of the Martian landscapes (Sven, which one
are you using?) and see what I can do. But first I am trying to unlock a
HDD from an old PVR and having problems with it and the utility I am
using hdat2.exe
So it might take a while.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2017 um 03:44 schrieb Sven Littkowski:
> When talking about that "inside_Vector", I refer to Clipka's information
> he gave me, when I mentioned that I wanted to have solid shapes (and not
> hollow meshes) for POV-Ray.
>
> My understanding of Clipka's information was, that I should open the STL
> meshes in Blender and that I would find there an option to add that
> mysterious "inside_vector".
Actually no; the workflow I tried to suggest was to export the mesh to
POV-Ray format as usual, then edit the generated POV-Ray file manually,
adding `inside_vector y` (or whatever direction corresponds to "up") to
the mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> 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.
I'd be interested in seeing a diagram of this - and I thought about coding one
up myself - potentially for use in the docs (since this comes up a lot)
But the information that I need to do that is:
POV-ray shoots a ray in the direction specified by `inside_vector` _FROM_ ---
where?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
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.
2) Perhaps the 'shoot-from point' (or from *multiple* points) is actually the
surface of the other intersecting object. That would *seem* to make sense--
because a successful vector direction should naturally point toward the inside
of the now-partial 'hull' (of the mesh object), *as seen from* the other
object's surface. And if the mesh isn't a completely CLOSED one-- if there's a
'hole' in the mesh somewhere-- then the chosen inside_vector direction (if not a
'good' one) could conceivably point at that hole, with NO surface triangle being
detected there... resulting in that particular part of the CSG construct not
being rendered at all. (Possibly an example of the 'odd/even' rule that Clipka
mentioned?-- a hole returning 'ZERO intersections', which is 'even'.)
It's also my understanding that each and every triangle of the 'partial CSG'd
hull' is tested with the inside_vector. In other words, it isn't just a one-time
affair.
That's about as far as I've gotten ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> 2) Perhaps the 'shoot-from point' (or from *multiple* points)
I would think it would HAVE to be multiple points - because
(a) if it were just a single point, then
(1) it wouldn't make any sense, as there would only ever be one ray
(2) and/or you'd get a solid wedge of sorts
(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?
This suggests that a similar mechanism might be used in reverse to take a
non-mesh object and construct a point cloud where the ray-[object]surface
intersection points are. Then "just" triangulate the point cloud.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17.08.2017 08:48, clipka wrote:
> Am 16.08.2017 um 03:44 schrieb Sven Littkowski:
>
>> When talking about that "inside_Vector", I refer to Clipka's information
>> he gave me, when I mentioned that I wanted to have solid shapes (and not
>> hollow meshes) for POV-Ray.
>>
>> My understanding of Clipka's information was, that I should open the STL
>> meshes in Blender and that I would find there an option to add that
>> mysterious "inside_vector".
>
> Actually no; the workflow I tried to suggest was to export the mesh to
> POV-Ray format as usual, then edit the generated POV-Ray file manually,
> adding `inside_vector y` (or whatever direction corresponds to "up") to
> the mesh.
>
Ohhhh, okay. That is now one of the clarifications I needed. Thanks. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17-08-17 à 15:18, Bald Eagle a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>> 2) Perhaps the 'shoot-from point' (or from *multiple* points)
>
> I would think it would HAVE to be multiple points - because
> (a) if it were just a single point, then
> (1) it wouldn't make any sense, as there would only ever be one ray
> (2) and/or you'd get a solid wedge of sorts
> (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?
The answer for this one is NAN (Not A Number)
>
> This suggests that a similar mechanism might be used in reverse to take a
> non-mesh object and construct a point cloud where the ray-[object]surface
> intersection points are. Then "just" triangulate the point cloud.
>
>
>
The test ray is shot from amy point that need to be tested to see wether
or not it's inside the mesh.
The case of a triangle been perfectly parallel to the vector do exist
and lead to artefacts. In that case, you need to slightly alter the
direction of the vector. Adding something like +0.000001 to one of the
components should be enough in most cases, but there are situations
where it can cause another triangle to become parallel to the vector.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17-08-17 à 15:23, Sven Littkowski a écrit :
> On 17.08.2017 08:48, clipka wrote:
>> Am 16.08.2017 um 03:44 schrieb Sven Littkowski:
>>
>>> When talking about that "inside_Vector", I refer to Clipka's information
>>> he gave me, when I mentioned that I wanted to have solid shapes (and not
>>> hollow meshes) for POV-Ray.
>>>
>>> My understanding of Clipka's information was, that I should open the STL
>>> meshes in Blender and that I would find there an option to add that
>>> mysterious "inside_vector".
>>
>> Actually no; the workflow I tried to suggest was to export the mesh to
>> POV-Ray format as usual, then edit the generated POV-Ray file manually,
>> adding `inside_vector y` (or whatever direction corresponds to "up") to
>> the mesh.
>>
> Ohhhh, okay. That is now one of the clarifications I needed. Thanks. :-)
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
One last thing : You need to add the inside_vector at the end ot the
mesh's definition. Normally, it's just before it's last closing brace "}".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
