I am trying to import an .obj file that contains some geo-referenced model. All vertices are defined with an absolute offset (no mesh transformation) and because of that, the vertices coordinates are very big, for instance:
v 1024199.614999999 6280752.805999999 0.9109999999890448
Now, the .obj parser, but also the resulting imported mesh, store the data in arrays of aiVector3D, which is defined as follow:
typedef aiVector3t<float> aiVector3D;
I would like all the import pipeline to read my values (at least the vertices position) using double precision floating points.
I guess I will have to hack the source at some locations, but before I start this, I would like to check with you guys if there was a better existing method ?
Thanks a lot,
Greg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have exactly the same problem and I think this would be very common in all software used in the professional GIS market.
Would it be possible to:
Have the precision definable at compile time (float would be default)
Have a 'typedef float real' or '#define REAL float' somewhere central and then use this 'real' instead of float everywhere applicable
Users needing double precision would then only need to change the definition of real before compiling assimp
While I understand the rationale by why float was chosen in the first place (not much hardware or 3D software that can render double precision directly anyway). This pattern of storing the vertices in real world coordinates is unfortunately very common in our field of work and makes assimp useless for us.
Alternatively if we successfully create a patch that implements this, would the maintainers consider adopting this patch?
Having to rewrite assimp every time we need to update it is not very tempting.
Last edit: Stig R Kristiansen 2015-07-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we faced the same problem as well (UTM coordinates), and were able to modify the library source to address our needs:
- Introduce a new type in defs.h : typedef double aiCoordType
- Modify aiVector3D, et al. to use aiCoordType
- Rebuild and weed out the various compilation errors; some needed function redefinitions, some needed function duplication (overloads)
- Once it built, revisit and look for compilation warnings (mostly operations concerning assigning a double value to a float) that are a) in the formats that we're interested in or b) seemed dangerous and tweak those cases, mainly by using either using aiCoordType, 'auto', or a cast.
- Rebuild our application to use the new AI object types. No change to our importer/exporter code was required.
Of note: most of the formats that we deal with are fine using double-sized coordinates; some have explicit support for them, which AI does not support (on the export side, as I recall). Flip side: STL binary is by definition 32-bit floats, so this will always be a loser case for UTM-based models.
Total time to do the above: less than a day (working through a number of test cases, round-tripping to/from other formats took extra time). Many files in the AI library were changed, but only a little bit. Floating point constants and explicit casts are a pain point, since you can't fix those automatically throughout. But they're 'mostly harmless' in the cases I examined. Yes, there's a slight slowdown (didn't benchmark it though) and obviously memory requirements for aiScenes is about doubled. That's a transient state for us, though, so not a huge deal. Updating to a new version of the library will also not be fun, but will be easier next time, whenever that is. One bonus: doing this conversion turned up a problem with our 3D renderer that we were able to find and fix.
Suggestion: please consider using a typedef'd coordinate type, as we did with aiCoordType, even if you base it on 'float', and carrying it through your external data structures. That way, if you ever decide to support double-based coordinates (maybe as a library configuration option), it should make it easier to do the conversion).
Cheers.*
Last edit: Jeff Howe 2016-03-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi! I use assimp C++ lib as nuget package in a VisualStudio project. I would like to know when you will provide a double precision compiled version through NuGet.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi! I use assimp C++ lib as nuget package in a VisualStudio project. I
would like to know when you will provide a double precision compiled
version through NuGet.
Hi,
I am trying to import an .obj file that contains some geo-referenced model. All vertices are defined with an absolute offset (no mesh transformation) and because of that, the vertices coordinates are very big, for instance:
v 1024199.614999999 6280752.805999999 0.9109999999890448
Now, the .obj parser, but also the resulting imported mesh, store the data in arrays of aiVector3D, which is defined as follow:
typedef aiVector3t<float> aiVector3D;
I would like all the import pipeline to read my values (at least the vertices position) using double precision floating points.
I guess I will have to hack the source at some locations, but before I start this, I would like to check with you guys if there was a better existing method ?
Thanks a lot,
Greg
We only have single precision accuracy because for render stuff this was more than enough in the past. So you have to do this on your own, I guess.
Kimmi
Hi,
We have exactly the same problem and I think this would be very common in all software used in the professional GIS market.
Would it be possible to:
While I understand the rationale by why float was chosen in the first place (not much hardware or 3D software that can render double precision directly anyway). This pattern of storing the vertices in real world coordinates is unfortunately very common in our field of work and makes assimp useless for us.
Alternatively if we successfully create a patch that implements this, would the maintainers consider adopting this patch?
Having to rewrite assimp every time we need to update it is not very tempting.
Last edit: Stig R Kristiansen 2015-07-29
See https://github.com/assimp/assimp/issues/638
Yes, we faced the same problem as well (UTM coordinates), and were able to modify the library source to address our needs:
- Introduce a new type in defs.h : typedef double aiCoordType
- Modify aiVector3D, et al. to use aiCoordType
- Rebuild and weed out the various compilation errors; some needed function redefinitions, some needed function duplication (overloads)
- Once it built, revisit and look for compilation warnings (mostly operations concerning assigning a double value to a float) that are a) in the formats that we're interested in or b) seemed dangerous and tweak those cases, mainly by using either using aiCoordType, 'auto', or a cast.
- Rebuild our application to use the new AI object types. No change to our importer/exporter code was required.
Of note: most of the formats that we deal with are fine using double-sized coordinates; some have explicit support for them, which AI does not support (on the export side, as I recall). Flip side: STL binary is by definition 32-bit floats, so this will always be a loser case for UTM-based models.
Total time to do the above: less than a day (working through a number of test cases, round-tripping to/from other formats took extra time). Many files in the AI library were changed, but only a little bit. Floating point constants and explicit casts are a pain point, since you can't fix those automatically throughout. But they're 'mostly harmless' in the cases I examined. Yes, there's a slight slowdown (didn't benchmark it though) and obviously memory requirements for aiScenes is about doubled. That's a transient state for us, though, so not a huge deal. Updating to a new version of the library will also not be fun, but will be easier next time, whenever that is. One bonus: doing this conversion turned up a problem with our 3D renderer that we were able to find and fix.
Suggestion: please consider using a typedef'd coordinate type, as we did with aiCoordType, even if you base it on 'float', and carrying it through your external data structures. That way, if you ever decide to support double-based coordinates (maybe as a library configuration option), it should make it easier to do the conversion).
Cheers.*
Last edit: Jeff Howe 2016-03-08
I created this branch: https://github.com/assimp/assimp/tree/feature/configured_precision
Kimmi
Hi! I use assimp C++ lib as nuget package in a VisualStudio project. I would like to know when you will provide a double precision compiled version through NuGet.
Thanks!
Good question. Who is the maintainer for that package?
Kim
Geraldine Olivier golivier33@users.sf.net schrieb am Mi., 25. Okt. 2017,
11:54: