Closed GoogleCodeExporter closed 8 years ago
Well all the library is doing is forwarding that property config to the
unmanaged importer, so the wrapper doesn't play a role in the vertex normal
generation. Couple of ideas:
-Does the source model already have normals? Per to the documentation, the post
process normal generation is skipped if they are present.
-Is the smoothing angle too low? Face normals that exceed the angle will not be
smoothed, so those vertices will also have a hard/flat look.
I would recommend loading your model up in the Assimp Viewer:
http://assimp.sourceforge.net/main_viewer.html
Original comment by nicholas.woodfield
on 13 Aug 2013 at 1:57
Your library is generally - cool!
There are two problems:
1. if model loader class (3ds, obj,stl ..) generate normals (usually those are
surface normals)- library will IGNORE any attempt to generate vertex normals.
First line in:
bool GenVertexNormalsProcess::GenMeshVertexNormals (aiMesh* pMesh, unsigned int
meshIndex)
is:
if (NULL != pMesh->mNormals)
return false;
While you don't have (your .net code) influence on dll library you can make few
improvement by adding more control over conversion (ConvertFrom*) because that
doesn't work as it should.
I have had luck with:
Scene
model=importer.ImportFile(fileName,PostProcessPreset.TargetRealTimeMaximumQualit
y);
Then I simply use data from model.Meshes.
I believe problems with ConvertFrom* functions are that there's no possibility
to set all flags via importer.SetConfig(config); so things like joining
vertices can't be issued.
Thanks for this library!
Z.
Original comment by z.janke...@gmail.com
on 13 Aug 2013 at 2:26
Both convert and import follow the same process in preparing config properties
and post processing.
I think there's some confusion on how to setup these. The configs are
name-value pairs and you can set as many as you'd like via SetConfig. The join
identical vertices option is not a config, but a post process step so it has
nothing to do with SetConfig(), although some configs serve as input to a post
process step. That pp step most likely clears existing vertex normals, which is
why TargetRealTimeMaximumQuality is working out. You can just as well have
specified:
PostProcessSteps.GenerateSmoothNormals | PostProcessSteps.JoinIdenticalVertices
The preset like the one you used have both of these flags set.
There *is* a chance that the problem may lie with the data in the export data
blob. I don't know how the obj exporter is written (unlikely, although
possible, it may not be writing out the correct normals). The export data blob
contains an export file format, not the same data structure you see returned
from ImportFile.
Original comment by nicholas.woodfield
on 13 Aug 2013 at 3:32
Original comment by nicholas.woodfield
on 21 Aug 2013 at 1:42
Original issue reported on code.google.com by
z.janke...@gmail.com
on 11 Aug 2013 at 8:06