I think I observed the same problem but in another context:
I wrote an IDTF file containing MESHs and lineset
The MESH represents a surface and the lineset contains the wireframe of this surface.
When I compiled the IDTF file with IDTCcompiler.exe, I obtained the surface and the wireframe, but they are not aligned and an offset (that increases moving away from the origin) appear.
This seems to be the same problem described by "wethat"
I used the following options for the compiler:
-pquality 1000 -tcquality 1000 -gquality 1000 -tquality 1000
BUT the offset is still there ... is there an option that I can pass to IDTFcompiler to emulate the solution proposed in the last mail?
Thank a lot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gets rid of the offset. Is there a way to get even higher quality than this. With this setting we get 5 significant digits on the line positions (for a relatively small bounding sphere).
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got problem with line sets being deformed. As I have red all posts I'm aware I need "patched" IDTFConverter.exe file. Unfortunately my code is written in c# and visual studio 2010 is not converting properly older solutions. Can someone give me a link to latest, with all known issues repaired, executable of IDTFConverter (win32)?
Thank you in advance ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
UPDATE: I was trying to show mesh structure for finite element models. I was generating faces from 3 or 4 node element definition and then line set based on this same definition, since outline function is showing only some edges.
@mvid -> your sollution seemed fine, till' I've tried it with some big complex model. With large models the offset is still there. It's impossible to show mesh this way…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But to show mesh structure you have to use "Solid Wireframe" in Adobe Reader, not "Solid Outline" as you are apparently trying now.
On the other hand, since you now can compile U3D tools yourself, there is an option to trace how compression works in U3D and try to set compression parameters yourself. As far as I remember I failed to make compression work the same way for line sets and point sets based on the same data, when I had the offset problem, but I did not try to foil compression by tweaking the compression code, only by setting parameters to drive existing code my way.
One more option is to try to use PRC format. There are compressed and uncompressed modes there. In uncompressed case the offset problem should not appear. There is some open source code to output uncompressed line sets and meshes in PRC - and several commercial offerings, including former Adobe libs, that must support every feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Solid Wireframe or Solid Outline make no difference to me since my mesh consist of 3 and 4 nodes, and mesh in u3d is always 3 node.
I will try to track this myself, just wanted to mention that this solution is not complete.
On the other hand, PRC format sounds promising since u3d gave me more downs then ups. Is there something similar to IDTF there or you just have to write your own binary file creator. I'm working with raw data and using external software for surfaces is not an option.
Thank you very much for all your support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
May be replacing lines with triangle cylinders can solve your problem?
Or make any triangle or quad a separate mesh and use Solid Outline?
BTW you may have to do that for translucent meshes in some cases.
As to PRC - there are both libraries to output PRC and converters to PRC from established formats.
Take a look at tetra4d.com and pdfgenerator3d.com (former Adobe 3D tools), pdf3d.com (rev. engineered code, likely).
I work on PRC output code in Asymptote (asymptote.sf.net). It is LGPL. So one can take the relevant piece, "PRC driver", compile it as a library and use in any project. To get recent code contact me by e-mail master at iaas.msu.ru. I am fixing mesh and line set support right now. But - only uncompressed mode, no lossy compression of data, so no offset problems on one hand and large size of output file on the other. Or if you have output to some 3D format already working, a converter to PRC can be built by blending Asymptote "PRC driver" and Assimp 3D import library, so you'll have an external program, just as you have IDTFConverter now.
> Thank you very much for all your support.
Guinea pigs aspiring a career in research AKA early adopters (volunteer testers) are always welcome in FOSS world ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
we are seeing a strange effect when we create linesets with the U3D export library.
We put in a line vertex coordinate of lets say:
x = 26.0, y = 26.0, z = 35.0
When looking at the object properties in the Acrobat 3d toolkit, the line has vertex has now
x = 26.4562, y = 25.6894, z = 34.8916
No transformation as involved. Teere is only a single node with an identity transform.
What is going wrong here (no I did not have a beer last night ;-)
Regards, Peter
Hi,
Acrobat 3D Toolkit and any 3rd part software is "black box" for us.
We can't guaranty that there are no transformations before rendering.
Thanks, Roman
Hi Roman,
unfortunately these offset are visible in the sample player as well (the sample player just does not have an easy way to measure coordinates).
With a little bit of debugging we saw that the positions are ecorrect up to CIFXLineSetEncoder::EncodeX
When debugging the sample player however, we see that the position come in wrong (CIFXLineSetDecoder::ReadLineUpdateX)
Peter
Hi,
so we need to investigate this issue.
Thanks a lot!
Hi Roman,
the offsets are an artefact of the index compression used for linesets (where point coordinates are discretized into U32).
Turning up quality using:
mLineSetResource->SetQualityFactorX(IFX_MAXIMUM_QUALITY_FACTOR,IFXMarkerX::POSITION_QUALITY);
solved the problem for know.
We will get new issues for long and thin models where index compression is not optimal.
Peter
I think I observed the same problem but in another context:
I wrote an IDTF file containing MESHs and lineset
The MESH represents a surface and the lineset contains the wireframe of this surface.
When I compiled the IDTF file with IDTCcompiler.exe, I obtained the surface and the wireframe, but they are not aligned and an offset (that increases moving away from the origin) appear.
This seems to be the same problem described by "wethat"
I used the following options for the compiler:
-pquality 1000 -tcquality 1000 -gquality 1000 -tquality 1000
BUT the offset is still there ... is there an option that I can pass to IDTFcompiler to emulate the solution proposed in the last mail?
Thank a lot!
Hi Roman,
could the offset be an artefact introduced by the quantization done in
CIFXLineSetEncoder::CalculateQuantizationFactorsX ?
This kind of fits with out observation that the
error bocomes different when we add extra lines
Peter
Hi Roman,
I think we solved the mystery. Setting
mLineSetResource->SetQualityFactorX(IFX_MAXIMUM_QUALITY_FACTOR,IFXMarkerX::POSITION_QUALITY);
gets rid of the offset. Is there a way to get even higher quality than this. With this setting we get 5 significant digits on the line positions (for a relatively small bounding sphere).
Peter
Hi,
I've got problem with line sets being deformed. As I have red all posts I'm aware I need "patched" IDTFConverter.exe file. Unfortunately my code is written in c# and visual studio 2010 is not converting properly older solutions. Can someone give me a link to latest, with all known issues repaired, executable of IDTFConverter (win32)?
Thank you in advance ;)
Go get my cmake repack. Cmake will mekt you a VS 2010 solution.
And while repacking I already set default compression to be minimal.
Thank you very much. Everything is working really nice.
UPDATE: I was trying to show mesh structure for finite element models. I was generating faces from 3 or 4 node element definition and then line set based on this same definition, since outline function is showing only some edges.
@mvid -> your sollution seemed fine, till' I've tried it with some big complex model. With large models the offset is still there. It's impossible to show mesh this way…
But to show mesh structure you have to use "Solid Wireframe" in Adobe Reader, not "Solid Outline" as you are apparently trying now.
On the other hand, since you now can compile U3D tools yourself, there is an option to trace how compression works in U3D and try to set compression parameters yourself. As far as I remember I failed to make compression work the same way for line sets and point sets based on the same data, when I had the offset problem, but I did not try to foil compression by tweaking the compression code, only by setting parameters to drive existing code my way.
One more option is to try to use PRC format. There are compressed and uncompressed modes there. In uncompressed case the offset problem should not appear. There is some open source code to output uncompressed line sets and meshes in PRC - and several commercial offerings, including former Adobe libs, that must support every feature.
Solid Wireframe or Solid Outline make no difference to me since my mesh consist of 3 and 4 nodes, and mesh in u3d is always 3 node.
I will try to track this myself, just wanted to mention that this solution is not complete.
On the other hand, PRC format sounds promising since u3d gave me more downs then ups. Is there something similar to IDTF there or you just have to write your own binary file creator. I'm working with raw data and using external software for surfaces is not an option.
Thank you very much for all your support.
May be replacing lines with triangle cylinders can solve your problem?
Or make any triangle or quad a separate mesh and use Solid Outline?
BTW you may have to do that for translucent meshes in some cases.
As to PRC - there are both libraries to output PRC and converters to PRC from established formats.
Take a look at tetra4d.com and pdfgenerator3d.com (former Adobe 3D tools), pdf3d.com (rev. engineered code, likely).
I work on PRC output code in Asymptote (asymptote.sf.net). It is LGPL. So one can take the relevant piece, "PRC driver", compile it as a library and use in any project. To get recent code contact me by e-mail master at iaas.msu.ru. I am fixing mesh and line set support right now. But - only uncompressed mode, no lossy compression of data, so no offset problems on one hand and large size of output file on the other. Or if you have output to some 3D format already working, a converter to PRC can be built by blending Asymptote "PRC driver" and Assimp 3D import library, so you'll have an external program, just as you have IDTFConverter now.
> Thank you very much for all your support.
Guinea pigs aspiring a career in research AKA early adopters (volunteer testers) are always welcome in FOSS world ;)