stl2pov mirrored file bug - anyone solved it?

[Admin]

I'm doing Step 12 in my Eagle3D tutorial.

I'm using stl2pov v2.4.3 (version 2.4.0 also has this bug).

For some reason, when converting from a .stl to a POV-Ray .inc file the part gets mirrored. I never noticed this before because all my previous designs were symmetric . . .

I assume its a bug in stl2pov - has anyone resolved this issue? I emailed the author, but not sure when or if he'll reply and/or fix the bug.

See attached image. The left image is the .inc, the right image is the .stl.

[TrickyNekro]

Is this the same object you where talking about in the POV RAY EAGLE 3D tutorial...

Are you sure you aren't adding some unwanted rotation...
I guess out of laziness you used the same pattern for both up and down side...

So this could be a unwanted 180 rotation...
Just check the pov ray makefile to see any unwanted rotation... That's easy... ;-)

[Admin]

Its not a rotation, its a complete mirrored inversion. Look more carefully, there ain't no way a rotation can cause this issue

[Admin]

I just got an email back - its a valid bug:

After having done some digging, it seems that the STL format *assumes*  a
right-handed coordinate system[1].  POVray uses a left-handed coordinate system.

Since I didn't find any mention of coordinate systems in publicly accessible
documentation, stl2pov does not do any coordinate system transformation. The
fix will be to swap x and y coordinates in the output routine.[2]

I've also got another bug report about some programs generating invalid STL
normals, which is less trivial to fix. I'll put out a new release when I've
fixed both.

The temporary fix to that would be design your files with the coordinate system in mind . . . Unfortunately after making a file in AutoDesk Inventor, it won't allow you to change the coordinate system (I was unable to figure it out).

That said, I found another related bug - stl2pov assumes your .stl file is in units of mm. If you designed your file in inches, it'll shrink your part by 25.4x.

The temporary fix is to add this line in POV-Ray:

Code: [Select]

scale 25.4

[TrickyNekro]

POV uses millimeters as input... Should have expected this with the size....
What has this to do with the mirror...

And it should be using simple Cartesian for the objects... Although I don't know for sure...

Camera gets a little bit tricky, as it must be using something as cylindrical, it's noways simple Cartesian...

I am extremely surprised that something gets mirrored in povray...
Povray has 6 degrees of freedom....

Do you have an image of the part you want to place from downside..
Supposed you used the same pattern for upside and downside of the part this is a 180 rotation on a given axis...

Amen!

[Admin]

The bug isn't with POV-Ray, its a problem with stl2pov.

The real problem is that .stl files do not specify coordinates or units, causing stl2pov to guess wrong. I never noticed the problem before because typically electronics parts come in mm measurements, and most are symmetrical.

[TrickyNekro]

Is there a way to get the mathematical output from the cad program?

Then just do some writing in POV and link it ;-)

[Admin]

Is there a way to get the mathematical output from the cad program?

Then just do some writing in POV and link it ;-)

What do you mean by mathematical output?


I can always do work-arounds, but it just adds to the work. And remembering a workaround a year later might be a challenge for me

[TrickyNekro]

Well... with POVray you can put some equations and... well... draw a ride for the camera... Do some other 3D stuff...
Yeah I know... you must like pain to do so... xexexexe

BTW... this is slow... darn it... To process some 800X600 pictures for the first 100 it did ~78 min....
And it's only like 8 ~ 10 sec video... LOLz!!! I need a Grid...

[Admin]

Well... with POVray you can put some equations and... well... draw a ride for the camera... Do some other 3D stuff...
Yeah I know... you must like pain to do so... xexexexe

Yeap definitely a pain. Much faster/easier using CAD, which is why I'm using stl2pov.

BTW... this is slow... darn it... To process some 800X600 pictures for the first 100 it did ~78 min....
And it's only like 8 ~ 10 sec video... LOLz!!! I need a Grid...

The final version 3D fly-through of the Axon II consisted of 641 frames, requiring 6 hours of processing on my 1.8GHz laptop. I used a big laptop fan to speed it up by ~30%. Like 40 seconds of 640x480 video . . . and it took me like a half dozen attempts before I got it the way I liked it.

[TrickyNekro]

At least it's easy to understand how to code it...

It really kills me it isn't clearly C programming...
I would have been easier...

I saw the video... Not that I haven't seen it before but... Now I can understand how hard it was...

If I am not wrong it's a spiral course with a down counting radius...

But how do you have the camera to look all the time ahead... It needs... more maths...

I mean you know... You need the tangent or the first derivative of the course...
That's not hard... But did you do it that way??? 

sorry for hijacking... But you know... your problem's solved anyways... (or came to a halt)

[Admin]

I defined the path by defining a set of camera locations, a set of camera angles, and the travel time between each point. POV-Ray then fits a spline between the points.

[TrickyNekro]

Yeah that sounds lazy... let the PC do the dirty curve work...

But no matter it was nice 

I'll give it a try