I'm testing the example https://github.com/petrbroz/forge-potree-demo trying to import a NWD and point cloud into the Forge Viewer but can't make them match the coordinates.
I confirmed on Navisworks that both PC and model are aligned at 0,0,0. But they are displaced more than 200' in the Viewer.
What we did tried
Point cloud was converter using Potree converted 1.6 and 1.7 https://github.com/potree/PotreeConverter/releases/tag/1.7
The point cloud is scaled from meters to feet using let scale = new THREE.Vector3(3.28084,3.28084,3.28084);.
The models are being inserted with a global offset of 0,0,0. globalOffset: {x:0,y:0,z:0}
We created a sphere at a know point directly in Threejs using coordinates in foots and it matches the location on the NWD.
We found that potree converter is not 100% compatible with the sample, a quick fix is needed on the line 464 to read categories created by the converter.
var pointAttributeName = pointAttributes[i].name.toUpperCase().replaceAll(' ','_');
Also we needed to add a new category around line 434
PointAttribute.RGBA = new PointAttribute(PointAttributeNames.COLOR_PACKED, PointAttributeTypes.DATA_TYPE_INT8, 4);
Without those two latest fixes we can't load the point cloud.
What are we missing?
We can override the location by hand but the final coordinates doesn't make sense with the project. Too arbitrary. Could the two fixes be the problem? What should be an alternative?
We found the problem, potree was using a bounding box based on absolute units from the actual point cloud bounding box.
This makes sense if you want the point cloud to be on the center of the scene. But not at our case.
So, if you override this feature by changing potree.js bounding box set from
boundingBox.min.sub(offset);
boundingBox.max.sub(offset);
tightBoundingBox.min.sub(offset);
tightBoundingBox.max.sub(offset);
to
tightBoundingBox.min.sub(offset);
tightBoundingBox.max.sub(offset);
boundingBox.copy(tightBoundingBox);
the point cloud will align with the model.
FYI: The fixes we made where actually making us able to run potree converter 1.7 instead of 1.6 as specified in the demo readme.
Related
I can't find a way to get the actual camera direction neither in first person mode nor in third person: the vertical element of the data is missing, it's just constantly shows zero. I'v tried to get the camera data using PhysicsCast.instance.getRayFromCamera() and also by Camera.instance.rotation
None of them work. Also I found an older project, this one
https://github.com/NoahWarnke/DCLBlocks and within the new decentraland version it also doesn't work as it's supposed to be working. Is there a way to get the actual camera direction, pointer direction in the new Decentraland version?
Before question,I seached many places, I find some similar idea but without my solution.And my question can be also described as how to recalculate the model's uv to fix the panorama designed for six faces skybox.
Recently,I came upon a unique way to get fluent 3D roaming experience on matterport's Official network https://matterport.com/gallery/
I just want to know how did they do that?Their product is very fluent when swich the panorama picture.
After I roaming many times,I found the secret. I realized that the panorama carrier they use is not box or sphere,but is the object they show first!The evidence is that when switch the point,the object such as chair and table would have their own shadow(one chair have two image one stand up and the other one lie on the floor
With the object in panorama paste on their own correspond object and with depth information the roaming switch become more fluent (As for why they do not use the object directly ,I think because of the limited hardware,Many irregularity faces which get from scanning equipment cannot be use directly
And I want to use this idea in my project ,I have a group of six panorama which can paste on a boxGeometry perfectly,and I just want to paste them on model.but I stuck in project 360 degree.Yes I just find how to project one direction but I cannot project the remaining five.
var _p=BufferGeometry.attributes;
for (var i = 0; i < _p.position.count; i++){
var uvtempbeforeconvert= ( new THREE.Vector3(_p.position.array[3*i],_p.position.array[3*i+1],_p.position.array[3*i+2]) ).clone().applyMatrix4(houseObject.matrixWorld).project(camera1)
//use the worldvertices to get its screen coordinate
if(uvtempbeforeconvert.x<1&&uvtempbeforeconvert.x>-1 && uvtempbeforeconvert.y<1 &&uvtempbeforeconvert.y>-1) {
VerticesArray1.push(_p.position.array[3*i],_p.position.array[3*i+1],_p.position.array[3*i+2]);uvArray1.push(uvtempbeforeconvert.x*0.5+0.5,uvtempbeforeconvert.y*0.5+0.5);
Yes,I success in calculating one direction.BUT I cant deal with the triangle faces which occupy two more view frustum,like a face at the edge of the box.
How should I deal with this problem?Or I run in the FALSE direction at first?Which direction should i run in ?
After asking many people,I just find that I need to usd shadermaterial in threejs ,and use a function named cubetexture,samplercube.With that I can get the pixel color what I need!
I'm trying to implement normal maps in a ThreeJS fragment shader, but it seems as though a key feature, computeTangents, has been lost in recent versions.
Here is a working demo using an older version of Three:
http://coryg89.github.io/technical/2013/06/01/photorealistic-3d-moon-demo-in-webgl-and-javascript/
ThreeJS is using computeTangents() to add an attribute called "tangents" to the vertex which is sent to the shader.
So I researched as much as I could and tried using a shader only method of computing the tangent, but this requires dFdx which causes an error about GL_OES_standard_derivatives in the shader on my Macbook Pro.
Then I tried converting the geometry from a simple cube to buffer geometry for use in the BufferGeometryUtils.computeTangent() function, in order to generate the tangents there, but that requires "indexed geometry", which isn't present in basic geo created by ThreeJS.
From the original demo, this is the line I need to recreate using the latest ThreeJS:
var mesh = new THREE.Mesh(geo, mat);
mesh.geometry.computeTangents();
Repo here:
https://github.com/CoryG89/MoonDemo
Is it possible to get this demo working using the new version of Three?
I found the answer to this. For the demo above, it required changing the THREE.SphereGeometry to THREE.SphereBufferGeometry.
var geo = new THREE.SphereBufferGeometry(radius, xSegments, ySegments);
Then I had to add the BufferGeometryUtils.js file and use the following code:
THREE.BufferGeometryUtils.computeTangents( geo );
This got the demo working again.
I want to publish the data in the Oracle DBMS.
Since the SRS of the data (which is EPSG:3093) is different from the SRS the client wants (which is EPSG:5179), it must be transformed.
So, I’ve set the layer property on the Edit Layer page as follows:
Native SRS: EPSG:3093 (Tokyo / UTM zone 52N)
Declared SRS: EPSG:5179 (Korea 2000 / Unified CS)
SRS handling: Reproject native to declared
The problem starts now.
When I clicked ‘Compute from data’ for Native Bounding Box, it displays the result coordinates in Declared SRS, no Native SRS.
Is this the correct behavior? Since it is ‘Native Bounding Box’, the values should be in Native SRS.
Anyways when I clicked ‘Compute from native bounds’ for Lat/Lon Bounding Box, it correctly translates from ‘Declared SRS’.
Maybe it is correct to display the Native Bounding Box in Declared SRS then. (weird)
Anyways the client (OpenLayers 3) displays the data correctly.
But another problem remains.
Integrated GeoWebCache refuses to cache the tile images.
When the logging is set to VERBOSE_LOGGING, it logs the following error:
org.geowebcache.grid.OutsideCoverageException: Coverage [minx,miny,maxx,maxy] is [0, 4097, 6143, 6143, 11], index [x,y,z] is [3101, 2791, 11]
Since the caching works correctly for the other layers that does not transform the source data (since the data is already in EPSG:5179), that must be the transformation problem. Or another one.
When I see the coverage area of the EPEG:3093 on the Demos / SRS List page on the GeoServer, the area seems to be wrong. (It does not even cover Tokyo!) http://epsg.io/3093 displays the correct one.
Is this the cause of the caching problem?
Does GeoWebCache look for the coverage of the SRS and rejects the out-of-bound request?
My GeoServer version is 2.7.1.1.
You should store your data in the native projection as GeoServer will automatically reproject the data when a client makes a request in a different projection.
Then caching and the bbox will work.
I've traced the source code from GridSubset.java to GeoServerTileLayer.java and found that the content of the gwc-layers layer file had wrong gridSubset extent coords minY value. (It was too high)
I don't know why... Since I manage the gwc-layers layer files using Git, maybe some file date inconsistency confused GeoServer to sync the values. Or maybe I just broke something. I can only guess... Now after changing that value, caching works.
I have created a 3D model for printing in 3D an industrial layout.
Because I am not used in playing with professional 3D modeler software, I used SketchUp and the result was fine !
Now, I want to reuse the 3D models to make a dynamic visit of the "to-be" installation.
I exported each object in Collada format (DAE), and then try to used the collada importer in Threejs.
I have around 130 objects that I want to be able to select interactively, but I manage only to load one ...
I then get a try with STL loader (after having converting objects with MESHLAB from DAE to STL).
And then it works without any problem... but rendering problems.
In the linked picture (sorry, not enough reputation to insert image !), you can see that some parts of the objects seem the be "transparency", even if they have not this property set ! (only the ground is).
While moving with the TrackBallControl, some parts of the objects disappear from time to time....
I try with only one object, with or without the ground,...
I took snapshots of the problem I get :
fig 1, inside the red circle, the errors appears
fig 2, without the ground, it is the same : some parts that should be hidden are not
fig 3, the wireframe rendering shows not pb in the exported model...
link >> http://stackoverflow.legrandcondor.com/photo.html
link >> http://stackoverflow.legrandcondor.com/
Any ideas ? Suggestions before I get crazy ?! (Everything else works fine!)
Thankx in advance,
Your camera near plane is 0.1 and far plane is 1000000. Small values of the near plane can lead to depth-sorting precision problems.
In your case, set your near plane to, say, 100.
ref: http://www.opengl.org/wiki/Depth_Buffer_Precision
Also consider using OrbitControls so your model remains right-side-up.
three.js r.69