You may be (probably) misunderstanding what the inside_vector does / is for.

Likely your problem arises from an incompletely closed mesh.
You should use a mesh editing took to analyze / fix your mesh and try again.

https://news.povray.org/povray.general/message/%3C5997f81e%241%40news.povray.org%3E/#%3C5997f81e%241%40news.povray.org%
3E

- BE

Post a reply to this message

On 8/21/24 12:05, Ilya Razmanov wrote:
> Greeting wise ones,
> 
> When fiddling with meshes I came to conclusion that, if I rotate a mesh, 
> inside_vector assigned to it does not rotate together with mesh. As a 
> result, if I build a CSG like intersection with mesh and start rotating 
> that CSG, some imaginary parts appear and disappear from/to nowhere.
> 
> Is there any way to glue inside_vector to mesh so it gets transformed 
> together with it?
> 

Hi.

This is likely a longstanding bug in the official releases of POV-Ray. 
You are correct the inside vector should be rotated (transformed) along 
with the mesh - otherwise the inside test is unstable(*).

I proposed a fix to this many years ago on the developer mailing list 
and posted a pull request to github to fix it. At the time clipka 
suggested an alternate coding and I, either updated my pull request to 
that, or closed and submitted another exactly pull request which was 
exactly his suggested code(**).

I kept the pull request current via re-basing for many years, but it was 
in a collection of pull request from me never merged into the the 
POV-Ray source code. I closed all my pull requests on deciding to pursue 
my own branch (povr -> now yuqk) maybe 5-6 years ago. That closed pull 
req on the official code is very likely still searchable on github. I 
don't recall the fix off the top of my head. I confess I have not been 
doing much with POV-Ray of late - and I find myself too lazy in the 
moment to search for it (sorry).

Bill P.

(*) - There also is / was a longstanding unfortunate suggestion to make 
the inside vector axis aligned (and so problematic with many meshes) in 
the official documentation which I suggested be fixed too... Last I 
looked, the documentation had not been updated either. Some random 
vector would be better suggestion - and the truth is the vector should 
be set so as not to be parallel (or near parallel) with any face normal 
in the overall mesh.

(**) - clipka's fix was adopted in the yuqk fork. So it exists there, 
but off the top of my head I don't remember what it is well enough to 
suggest how to find it in the source via a search - and the yuqk code 
base is many thousands of changes different than POV-Ray proper these 
days, anyhow. What's found there probably won't exactly map to the 
official code base, though the core of the change will be exactly what 
you suggest for an update.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

(a lot of stuff)

Well - that's a bummer.

Maybe the thing to do (if you can tolerate the parse time and additional memory
overhead) is a workaround by writing a macro to reinstantiate your mesh with a
different inside_vector.

I guess maybe you'd have to edit your mesh file to use a variable name as the
inside_vector.  Then pass your desired rotation to the macro, have it declare
the inside_vector as that variable, and #include the mesh file, then rotate the
mesh.

yuk(q).

Post a reply to this message

On 21.08.2024 19:45, Bald Eagle wrote:
> You may be (probably) misunderstanding what the inside_vector does / is for.

Let's assume I understand how it works, and I just don't want to double 
filesize with useless "bottom mesh" (which still leaves roundoff defects 
but it's another another story). I did so with STL export for my 
img2mesh, it works, but let's say representing flat plane with thousands 
of triangles makes toad sad toad.

I want to cheat and avoid useless triangles, and with POVRay it works 
well, until I try to rotate the mesh. And, since inside_vector is a 
property of the object, I wished it will transform together with parent; 
at least this sound logical. Unfortunately, my beautiful logic goes to 
hell in the face of reality (btw, yesterday TV ad told me "diarrhea have 
many faces", either they know something hidden about this reality, or 
mess faces with faeces). That makes toad... you got the idea.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 21.08.2024 22:41, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> (a lot of stuff)
> 
> Well - that's a bummer.
> 
> Maybe the thing to do (if you can tolerate the parse time and additional memory
> overhead) is a workaround by writing a macro to reinstantiate your mesh with a
> different inside_vector.
> 
> I guess maybe you'd have to edit your mesh file to use a variable name as the
> inside_vector.  Then pass your desired rotation to the macro, have it declare
> the inside_vector as that variable, and #include the mesh file, then rotate the

I was thinking a bit in similar direction previously - if I define 
rotate vector in the beginning of the scene, and then use it as argument 
to rotate the thing, then I may probably refresh my school math 
knowledge and use the same vector to create inside one. Haven't tried it 
though, since, obviously, even I can't stop people from rotating objects 
the way they used to, i.e. first having an object, then rotating it, and 
not vs (hm, Alice, just think of rotating object before having one).

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> ... (btw, yesterday TV ad told me "diarrhea have
> many faces", either they know something hidden about this reality, or
> mess faces with faeces). That makes toad... you got the idea.


:D  I'm almost crying, I'm laughing so hard.
Might laugh so hard that I Schidt myself.  ;)

Thanks for that - lightened my morning mood, like "Spirit of Radio".

- BW

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

> I was thinking a bit in similar direction previously - if I define
> rotate vector in the beginning of the scene, and then use it as argument
> to rotate the thing, then I may probably refresh my school math
> knowledge and use the same vector to create inside one.

No need to refresh any math - let POV-Ray do the heavy lifting.

If you want to end up at <x, y, z> starting from <x0, y0, z0>, then take <x, y,
z> and rotate _inverse_ the rotation of your object.
See this "recent" thread:

http://news.povray.org/povray.advanced-users/message/%3Cweb.65c535447ecd0aa1f9dae3025979125%40news.povray.org%3E/#%3Cwe
b.65c535447ecd0aa1f9dae3025979125%40news.povray.org%3E

> Haven't tried it
> though, since, obviously, even I can't stop people from rotating objects
> the way they used to, i.e. first having an object, then rotating it, and
> not vs (hm, Alice, just think of rotating object before having one).

Well, yeah - but we do all sorts of things like that here.
Because there is no camera or light or object - it's all just math.
So you're just defining a rotation matrix to use later . . .  ;)

(Maybe there's also a way to minimize that bottom mesh to use as few triangles
as possible to close it.)

- BE

Post a reply to this message

On 21.08.2024 21:41, William F Pokorny wrote:

> This is likely a longstanding bug in the official releases of POV-Ray. 
> You are correct the inside vector should be rotated (transformed) along 
> with the mesh - otherwise the inside test is unstable(*).

Ah. I was hoping there is something simple I miss. No luck.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 22.08.2024 13:19, Bald Eagle wrote:
> :D  I'm almost crying, I'm laughing so hard.
> Might laugh so hard that I Schidt myself.  ;)

Believe me, their concept of multifaced (or may be even multifaceted) 
diarrhea scares even me. For 53 years I was living without thinking of 
it, and now there is a risk to see it in a nightmare.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 8/21/24 14:41, William F Pokorny wrote:
> and the truth is the vector should be set so as not to be parallel (or 
> near parallel) with any face normal in the overall mesh.

Blast...

"...with any face normal in the overall mesh."

Should read:

"... with any [triangle] face in the overall mesh."

My apologies for any confusion caused.

The storm in my head is more often making out through my finger tips 
days... :-(

Bill P.

Post a reply to this message