Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
While this seems nice, especially for my workflow (civil engineering), I would think this to be an massive software engineering feat, which could cause some serious performance penalties. I could be wrong about the performance penalties, but would the ends justify the means? Dev team, could you chime in? Am I wrong?
I'm quite on the fence with this one, because not only does it seem unnecessary, but even if the development team wanted to do it, like Mark said above, most of 3ds Max would have to be re-coded. Most likely that'll increase the minimum system requirements to run the program, and here's another thing, you'll need a Quadro card that supports double precision, in order to utilize 3ds Max's double precision to the fullest. (Kepler or Fermi, later cards to not support double precision as well.)
I'm not saying that it's a bad idea, but I just do not see much of in terms of a benefit : pay off ratio.
(If you know more about this than I do, and would like to inform me more about why it would be a major benefit to the program, please do not hesitate to let me know.)
I'm not a programmer either but I don't think that this issue has to do with graphic card. It's about porting 3ds max internal precision from 32 bit float to 64 bit float (double precision)
One simple and common example of why it would be a MAJOR benefit : if you do any kind of urban visualization where you have to work and navigate between very large and very small, distant objects you'll immediately uderstand that double precision is vital.
Just thought I might be helpful in suggesting this topic be broken up slightly as Double precision in viewport for transforms and such, what I think the poster is talking about, might not be as hard as double precision throughout the program. Sure it would still be a heavy dev lift but the rewards of double precision in view port for transforms are large but not as large for super accurate say bend tool results.
I agree with you Jeff, because double precision with transformations in the viewport would greatly increase the detail of which someone could make their scenes. Also, had they take up the challenge to make the entire program double precision capable, it would mean a whole new thing for 3ds Max:
- Higher RAM requirements
- Higher hard drive requirements for installation
- More CPU being used (hopefully 3ds Max will be completely multi-threaded before this happens)
- And most importantly, you'll need a video card that does well with double precision, or else it'll be the bottleneck to the whole workflow.
While double precision in the entire program would be "okay?", I agree with you as a whole Jeff, give me more control on how precise the transformations can be and I'll be happy.
I use max a lot for Civil Engineering stuff as well, but there is another work-around that would be much easier to implement until Max is fully re-written with double precision. Every time you import, say a dwg from Civil 3d you usually get in a specific coordinate system that puts the object (in my case roughly 150km off in X and 6400km in Y)
Why not simply add the ability to offset the geometry so that its moved closer to origo. Anyone used Cloud Compare? If you try opening something in high coords it will automatically "force you" to enter an offset. Max could have this as a feature.. and to make it easy, one would be able to save these offsets as presets.. typically all data in the same project will use the same coordinate system an therefore you'll need to offset it by the same amount...
Currently I do the above step in Civil3d or other CAD software but its an unnecessary extra step that should be built into max
A minimal-effort approach to this could be to implement the importer/exporter plugins in double precision, and add an offset/scale value to them such that data is being moved/scaled in 64-bit double precision before being converted to 32-bit single precision. If import and export remember the same offset/scale values, at least some problems could be worked around. FYI, here's an interesting page on this topic: http://www.ilikebigbits.com/blog/2017/6/1/float-or-double including a little table on the precision you will get from single/float: At a scale of the circumference of earth, you cannot model/animate at anything smaller than 2.4 meters with single precision (what 3ds Max currently has), whereas double precision goes down to nanometers...
Well.. Import/export is for sure not enough in my case at least. If you chain for instance 6 kinematics objects, the inaccuracy on the effector is unacceptable. Therefore I use my own double math for all internal calculations and narrow the results down to float-TMs. The same is ncessary with PhsyX, where just the entry and exit TMs use floats - otherwise the results would be totally wrong. An intermediate step could be that all internal matrix calculations are performed in double, but even this is unsolveable, as there are too many conversion cases (controllers & more) and it would also be a drawback in speed.
IMHO in the beginning this would require two different Max-Versions, a 'float' and a 'double' version - like we already had with x32/x64 - as it will affect also all external plugins!! If you look at the include files, such a huge change will be very error prone.
Honestly, I would put all other topics concerning the stability on top.
I think it's time that this becomes a priority. As @waqasziachaudhry has mentioned, Epic has already introduced changes to Unreal Engine 5 where the editor has full support for double and uses them when needed, especially with very large worlds / large world coordinates (LWC). Now since the editor supports double precision, the content creation apps like 3ds Max should also match it otherwise it's a problem. Cinema4D for a while now also has full doubles support. Max has always been more to do with games and film so we really need higher precision now to support the larger worlds support of current game engines. It's a pain to have to model in a restricted sense and then import things and place them in the game engine, whereas with double support you can more often model the entire scene in Max with all models where they should be and import the whole lot. I would much rather have double floats introduced soon rather than have small changes like menu editor as with the recent 2025 max release. With double precision, you are now also allowing pretty reasonable CAD modelling in Max too, meaning more people will be attracted rather than leaving Max for other, more precise apps. Max already has so many good features, precision is really the only one lacking. I mean, it benefits even the existing workflow of AutoCAD -> Max.
Some double math software is already there since several versions, but I think they recognized, that such a change would affect each dark corner of their software and also all external plugins. The main question which should to be answered is, if double and float will exist simulanously or if there will be two versions of Max? E.g. will we have the option to store mesh data either in double and float? Consider, if huge models (like e.g. point cloud data) will internally be saved in double, they require twice the memory. Currently I see it as benefit, that Max stores such data with floats.
@istanBut wouldn't that also hold true for all those other software, like Cinema4D? C4D has a lot of C++ plugins/extensions just like Max. So I don't think it's that different. Either way there will be some work, but at the end of the day it is not the same as changing a float to a string where the datatype is completely different. It's pretty much the exact same datatype with just more allowance. I suppose things like buffers would need to be checked and functions that are old and expect a hard limit to the bits they receive from a "float" type, but this can be handled, dare I say, in a straightforward manner. Of course, I'm not an Autodesk dev so if there is one reading, please correct me.
IMO for the transition, there can be a quick and dirty solution by introducing a separate code block that handles doubles. This can be triggered via an option in settings to "use doubles for vertex coordinates". The user checks this and the code then switches in the back to the logic that handles doubles. In fact, why leave it as transition, just have it a new feature so that people who know they are only making small objects, can leave this checked off. Although, maybe this can be handled the same way as Unreal where doubles are on by default but under the hood the system determines when it needs to use doubles.
Honestly though, it's 2024, the average person has at least 16 or 32 GB of memory, processors are crazy fast, have a lot of new features like AVX instruction sets etc. I don't think it would be much of a problem if the app uses slightly more memory. At the moment, every other software used together, such as Substance or Unreal or Photoshop all hammer the processor and use up whatever they can. Max is still stuck with a lot of core logic running on a single thread (for good reason of course) but even things that can be multi- are I think still not truly multi-threaded, so max is nowhere near its potential in performance. So I agree with you that it's a benefit to use doubles and it's worth any increase in resource requirements, which may be dealt with through the aforementioned option to enable/disable floats.
I mean think about this - I have around 7 million polygons open across 4 or so models in my scene and it's a large scene in terms of scale too and it's only using about 250 MB of memory. Even if we quadruple that, that's still nothing. Probably the only thing that hits Max and memory is textures and that's usually your GPU that crashes first as GPUs have the least memory compared to system ... and those will be all 4K textures too.
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")