Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gregory]

I've used anim8or almost exclusively for my models since at least 1999 so I'm familiar with the program.  It has been so long since the last update that I don't know if Steve is still working on it or not, but I'll post this in case he is as I haven't found any other modeler I like as well.

This is a problem that I've noticed for a long time, but it is so small that I wasn't sure what I was seeing.  I've had models go bad in small ways when saved in an an8 file and reopened and I've rebuilt them many times.  Points will move a tiny amount, twisting a sphere or pole, skewing a box, etc.  

Now I've spent three days trying to discover why my splines (using them to make neon tubing) have worked at first then later created twisted tubes instead of the nice smooth curves I had drawn.

It doesn't break consistently.  Ten minutes ago I redrew one of my splines, it extruded perfectly.  I saved the an8 file, reopened it, and the spline points had moved a tiny amount on the Z axis so the bends were twisted.  I fixed the spline point by point in order to post an example of it, saved it, but this time it opened fine (maybe because they'd been fixed manually).

Part of the problem is that even though I have Z unchecked, anim8or doesn't consistently put my Z axis at 0 for the points, even within the same spline they are back and forth across the zero line by a tiny amount, enough to ruin the extrusion.  What is really weird is that extruding before saving and reopening produces an okay result even though it looks the same.  After saving and reopening the file it is ruined.

What i want is to be able to keep all points where I put them.  In this case that means that when I uncheck Z they all shouldn't vary in Z at all.



Greg

[Gregory]

Here are results.

[Raxx]

I can't replicate this. I've tried half a dozen attempts but everything stays on the Z-axis before/after saving, before/after extruding. Perhaps it's dependent on your machine. What specs are they, have you tried it on a different computer and get the same results?

[Gregory]

I can't replicate this. I've tried half a dozen attempts but everything stays on the Z-axis before/after saving, before/after extruding. Perhaps it's dependent on your machine. What specs are they, have you tried it on a different computer and get the same results?

Hi Raxx,

Long time since I've posted here.  Good to see you, thanks for helping.  It isn't my machinery, this relatively new computer and my old ones all did it.

Look at Image9 that I posted above.  

I've attached the M spline test; change the extension to .an8 and try to extrude the centered octagon along the M.  Then look at the Left view up close and you should see that the points aren't in line (even though they all should be 0.000).

[Raxx]

Ok, I discovered the problem, thanks to the file you shared.

The problem is that you're working on too small of a scale. The height of that letter is maybe half of an Anim8or unit high. That means that in the workspace with how you are zoomed in (according to those attached pictures), each pixel represents an accuracy of a smaller floating point (decimal) value than what Steve programmed Anim8or to handle. So if you click and drag at that scale, Anim8or probably can't pinpoint a precise coordinate at that exact pixel since it's out of it's range, and instead returns gibberish at the very tail end of the x, y, and z coords.

Note also that since the interface only returns three decimal spaces, it's going to show '0' even if it's really 0.00015.

The solution: scale it up! 3D software is vector software, so scale ultimately doesn't matter. If you need true-to-world precision, then instead of setting 1 unit to equal 1 foot or 1 meter, set 1 unit to equal 1 cm and convert to metric if you're not already doing so, or just set 10 units to 1 foot (or whatever...I'm sure you get the point).

If you absolutely have to fix what you've got, open it up in notepad, go into the knots blocks of data, and set all of the Z-Coords to zero.

[Gregory]

Ok, I discovered the problem, thanks to the file you shared.

The problem is that you're working on too small of a scale. The height of that letter is maybe half of an Anim8or unit high. That means that in the workspace with how you are zoomed in (according to those attached pictures), each pixel represents an accuracy of a smaller floating point (decimal) value than what Steve programmed Anim8or to handle. So if you click and drag at that scale, Anim8or probably can't pinpoint a precise coordinate at that exact pixel since it's out of it's range, and instead returns gibberish at the very tail end of the x, y, and z coords.

Note also that since the interface only returns three decimal spaces, it's going to show '0' even if it's really 0.00015.

The solution: scale it up! 3D software is vector software, so scale ultimately doesn't matter. If you need true-to-world precision, then instead of setting 1 unit to equal 1 foot or 1 meter, set 1 unit to equal 1 cm and convert to metric if you're not already doing so, or just set 10 units to 1 foot (or whatever...I'm sure you get the point).

If you absolutely have to fix what you've got, open it up in notepad, go into the knots blocks of data, and set all of the Z-Coords to zero.

I just opened this page to type pretty much the same thing you just did

In the text version of the an8 file, the coordinates go to 5 places but are cut off in the knot dialogue.

An8
knot { (0 -0.01758 -0.10016)

dialogue
0.000  -0.018  -0.100

As for scale, I use 1 unit= 1 meter.  That matches other software native scaling that I use without having to modify the scaling, and the problem is that if I build larger, say at 10m instead of 1m, I still have the problem when I scale the model down for use elsewhere.  I really don't want to have to rescale every model I build outside of its storage version.

[Gregory]

Would this be solved by simply making the knot dialogue able to handle 5 decimal places?

[Raxx]

Well, I just tinkered around with it a little, and it seems that there may indeed be some sort of true bug or glitch involved. It seems that there's a small "sweet spot", a zoom and window size where it works well, though it seems it starts screwing up eventually after a large of knots have been placed. Then there's the large danger zone where it messes up after the first couple to first several knots. Perhaps it's relative to odd-numbered pixel-wide windows vs even vs too-large vs too big. At this point I think it's safe to say it's a bug, since it just got too complicated to explain rationally just by observation.

I don't think it'd be solved just by enabling 5 decimal places in the dialog box. It'd only grant you an easy way to set the Z to zero after it messes up.

[Gregory]

I've been messing around with the scaling and still the best would be for me to be able to keep it at 1 unit = 1 meter.  If only I could set the Snap to Grid at a small measure, like .001 I might be okay, but it won't allow it.

I haven't followed the forums for some time.  Has Steve been on?  Is he going to be updating Anim8or (can I hope for a bug fix on this?)

[Gregory]

If we could just have it be locked to Z at zero or whatever the first knot was set at when we uncheck the XYZ box it would be fine, just keep it on that plane.  Or even a feature similar to Flattening a face, moving selected points to one plane.

[Raxx]

If the Anim8or Scripting Language allowed for spline manipulation, I'd have made you a tool to reset all of the Z-Coords to 0 already. Otherwise some fancy RegEx in Notepad++ could fix your problem automatically, if you want to go the route of editing the .an8 file after each modification.

Now, this may be a foolish observation, but it seems that if you correct a problematic Z-Coord in the .an8 file, save it, and edit it, there's less chance of the Z-Coords acting up again. I could be wrong.

Lastly, there is B_Twist's E_Track plugin (located in the ASL Database), where you can make the spline paths out of regular edges and points, but it's somewhat unpredictable with sharp corners.

----

Steve drops by the forum to clean up the spammer mess fairly often. My moderator powers are limited to post management, so I shove the ugliness into a corner until he can deal with the source of the problem. Whether he actively reads the posts of the users or not, I can't say.

As for his plans on updating Anim8or, he's certainly planning on it, and has done work for the next version. In order to add certain new features, he's having to completely reorganize the internal data structures, which is a fairly large task. He plans on moving the dialog boxes to sidebars similar to how most other 3D software handles it, auto mirroring, and a few other features I promised not to tell

Steve doesn't have a lot of free time right now, so all we can really do is wait like we have been waiting, and hope Anim8or gets its due attention.

[Gregory]

I've been going through the file in a text editor, manually setting the z to 0 and it seems to stay put.  It is awfully tedious but seems like the only way.

Edit:  after trying that I see there's no practical way to do that, it will take far longer than the model's worth.  I need to make each point only use three decimal places.  Setting Snap to Grid won't allow me to use .001 as it is the lowest value in the range, even though that would make sense for my metric scale.  

hmm...   brewing more coffee...

If the Anim8or Scripting Language allowed for spline manipulation, I'd have made you a tool to reset all of the Z-Coords to 0 already. Otherwise some fancy RegEx in Notepad++ could fix your problem automatically, if you want to go the route of editing the .an8 file after each modification.

I'm using Notepad++ but I don't know what you mean there.

As for his plans on updating Anim8or, he's certainly planning on it, and has done work for the next version.

That's great news.

He plans on moving the dialog boxes to sidebars similar to how most other 3D software handles it, auto mirroring, and a few other features...

None of those are necessary as far as I'm concerned.  In fact I like the dialog boxes.  One of the reasons I've continued with anim8or over the years instead of the other packages I've used is the simplicity.  All I would want is that the numbers behave consistently.

[Raxx]

I'd say bug fixes are a given in any release, but there's no guarantee it'll be the bug(s) you want fixed.

Notepad++ has the search/replace feature where you can use regular expressions to find and replace strings based on patterns. This way you can just click a few buttons and it'll fix all of the splines in the .an8 file.

Here's the RegExp you search for:

Code: [Select]

(knot \{ \([-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)? [-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?) ([-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?)

and the code you replace:

Code: [Select]

\1 0

Should look like the attached file. It replaces all Z values in the first Point3 value of each Knot line in the .an8 file, since that seems to be where it's messing up. You can hit "Replace All" and it'll do it all in one go. It also keeps a history of your previous search/replace entries, so you probably don't have to commit it to memory