I'm having trouble loading different models in the viewer. I suspect the problem comes from mixing up different units (meters and millimeters) in the models.
So I have 3 Models:
IFC 1, is using millimeters as unit.
When loading the SVF derrivative into the viewer, doing
console.log(model.getUnitScale(), model.getUnitString());
outputs:
0.001, mm
IFC 2, using millimeters as unit. Getting the same output as IFC 1
Obj. Model of a simple cube with center of cube at origin [0, 0, 0]. This does not seem to have any inherent unit.
When loading the SVF derrivative into the viewer, doing
console.log(model.getUnitScale(), model.getUnitString());
outputs:
1, null
In order to load the models with the right coordinates I use the following options:
IFC 1 and 2:
{
globalOffset: {x: 1000000, y: 100000, z: 7000},
sharedPropertyDbPath: doc.getPropertyDbPath(),
}
Obj:
let mat = new THREE.Matrix4();
mat.makeTranslation(1000000, 100000,7000);
{
placementTransform: mat,
sharedPropertyDbPath: doc.getPropertyDbPath(),
}
The rationale here is that the IFC models are located far away from the origin, while the Obj model is located at origin. Using globalOffset for the IFCs seems necessary to get them to align in the viewer, using placementTransform is necessary to put the Obj close to the IFC models.
I'm struggling with the following problems here:
Navigating the models is hard, when highlighting the Obj model, it seems like it is set to using y-up or something, making it hard to do orientation navigation for the other models.
When trying to change zoom, only the Obj seems to be affected. Could this be due to different scale settings?
EDIT 1:
Looks like making the Obj cube the same size as the other models fixes the zooming problem.
Also, if loading the IFC files first, the orientation navigation is right. It's only when loading the OBJ file first that we get the "y-up orientation" problem
Edit 2:
The orientation navigation problem can be fixed with viewer.navigation.setWorldUpVector(new THREE.Vector3(0,0,1), false);.
Is it possible to also control behavior like this globally instead always letting the different models set the behavior?
I think the last loaded model will always have precedence over any previously set world-up vector. So if you want to control the world-up globally, you'll need to use the viewer.navigation.setWorldUpVector method manually after all the models have been loaded.
Related
I use the grid on the scene. The Building A (first image) setup is to be expected. But when I uploaded Building B, the orientation didn't match. Do I have to set it up in Revit ? or can I do it programatically.
Every model you load into the viewer is coming with its own metadata such as:
what is the "up" direction of the model
what is the offset of the model from the origin
what units is the model defined in
By default the viewer honors all these settings which means that, for example, if you load a Revit model that is defined in feet (and uses the Z-axis as the "up" direction), and then an Inventor model that is defined in meters (and uses the Y-axis as the "up" direction), the two models will have different scale and orientation.
To work around this issue, when loading (aggregating) multiple models in Forge Viewer, you can override any unit scaling, offset, or general 4x4 transformation that is applied to each model. For more details, look at https://forge.autodesk.com/blog/multi-model-refresher.
I'm using the Forge Viewer to display some models converted from IFC (2x3) files.
For some of them, the quality is perfect, but for others the rendering is very poor like the picture bellow.
I've tried to export in SVF, SVF2 and same result.
I've tired different settings to load the model
let config = {
keepCurrentModels: true,
applyScaling: { to: "m" },
applyRefPoint: true,
globalOffset: { x: 0, y: 0, z: 0 }}; //make the view flicker on weird rendered model
None of those settings improved the view except globalOffset who makes the view flicker.
Have you any idea how to fix this ?
This kind of deformation of geometries is typically an indication that the model is very far from the origin. So far that the GPU rendering starts running into floating point precision issues.
Loading the model with globalOffset: new THREE.Vector3(0, 0, 0) should help in this case as it would basically force the viewer not to re-apply the original global offset (which is potentially very large) to all geometry vertices. I'm not sure why the view would flicker after using this option, though, that might be a separate issue.
we run a webapplication using Autodesk Forge. In the webapplication we'd like to change surface apperances. Therefore we use the following Audodesk functions
...
event.fragIdsArray.forEach(frag => {
const model = this.viewer.model;
model.getFragmentList().setMaterial(frag, this.material)
var object = this.viewer.impl.getFragmentProxy(this.viewer.impl.model, frag)
object.updateAnimTransform()
}
The code works fine for Autodesk Revit imported model. Using imported IFC models does not work as expected. Both models were imported to the AD Forge viewer by ADs model derivate api.
To geht our expected results we tried to use MeshBasicMaterial and MeshPhongMaterial. Both with the same result: Revit model is fine, IFC model aint so.
In Order to lookup for some workaround we tried to copy the fragment meshes and creating overlays with the same mashes and changed materials. Code was like
...
var obj = this.viewer.impl.getRenderProxy(this.viewer.impl.model, frag)
var meshProxy = new THREE.Mesh(obj.geometry, this.material);
meshProxy.matrix.copy(obj.matrixWorld);
meshProxy.matrixWorldNeedsUpdate = true;
meshProxy.matrixAutoUpdate = false;
meshProxy.frustumCulled = false;
this.viewer.impl.addOverlay("parkett", meshProxy);
...
The result is shown in the image (right side is the expected result):
Somehow it looks like the image texture is not shown "detailed" enough...
Thanks in advance for any suggestion!
From the question I'm not entirely sure what the problem is. Are there no visible changes when applying a custom material to IFC models? Or is the custom material applied, but in a "wrong way"?
If the custom material is not applied at all, make sure that the model is not consolidated. You can ensure that using viewer.model.unconsolidate();.
If the custom material is applied but its texture doesn't look correct, it could be because the geoemtries in the IFC model do not include proper texture coordinates. In that case you would have to map the texture yourself, for example, using a custom shader: https://github.com/petrbroz/forge-basic-app/blob/custom-texture-mapping/public/CustomTextureExtension.js.
I'm loading multiple Revit models in the Forge modelviewer. To align them properly I am using the following load options as mentioned here
var modelOptions = {
sharedPropertyDbPath: doc.getPropertyDbPath(),
globalOffset: { x: 0, y: 0, z: 0 },
applyRefPoint: true,
isAEC: true
};
This works fine on Revit files where the project base point doesn't have too large coordinates. However, if the project base point of a Revit file has large coordinates ( like x:6698000, y:297500) then this results in shaking behavior when rotating the model or even a messed up triangulated view.
This problem also seems to happen when you set the placementTransform to a large coordinate as can be seen in the sample here
How can I solve this shaking behavior on these kind of models?
Can you try adjusting the offset using globaloffset...
Here's an example:
Model aggregating in viewer - coordinate issue
I have a basic three.js scene in which I am attempting to get objects exported from Blender (as JSON files with embedded morphs) to function and update their shapes with user input.
Here is a test scene
http://onthez.com/temphosting/three-js-morph-test/morph-test.html
The slab is being resized without morphs by simply scaling a box, which is working just fine.
I must be missing something fundamental with the little monument on top. It has 3 morphs (width, depth, height) that are intended to allow it to resize.
I am using this code to implement the morph based on users dat.gui input.
folder1.add( params, 'width', 12, 100 ).step(1).name("Width").onChange( function () {
updateFoundation();
building.morphTargetInfluences['width'] = params.width/100;
roofL.morphTargetInfluences['width'] = params.width/100;
roofR.morphTargetInfluences['width'] = params.width/100;
building.updateMorphs();
});
The materials for building, roofL, and roofR each have morphTargets set as true.
I've been going over the three.js examples here:
http://threejs.org/examples/?q=morph#webgl_morphtargets_human
as well as #webgl_morphtargets and #webgl_morphtargets_horse
Any thoughts or input would be much appreciated!
I believe I've reached a solution for my question I was under the impression that the JSON loader was preserving the morph target names to be used in place of an index number with morphTargetInfluences
something like morphTargetInfluences['myMorphTargetName']
but, after closer inspection in the console it seems like they should be referred to by number like morphTargetInfluences[0]
Not the most intuitive, but I can work with it.