Yes, but it looks like the position of this control point is wrong, as it seems that it is in the air, not on the model. Is it correct?
I noticed, that the view is cut, so 14 is not in the air.
Is there more areas like this? You should use CP right in the red circle and then realign again.
You also shouldn’t use these panorama images:
That could cause some problems with alignment, as you can get worse result:
Ok thanks, im try!!
i tried but is the same result
Can you show your result now?
When you compute your datasets separately (images and laser scans), do you have this in one of the results?
i think that is a problem with a photo taked on the ground… the difference with a drone photo is to much
Yes, it could be a problem. Do you have this also on another part of the model? I don’t see any control points in that area, like this:
You should add them and align again.
i have to do a new project with a new “competence”
but i have another problem, sorry for that…
i exported a obj and las file, but have a different coordinate with a original point cloud, why?
Hi, it depends, what you have set in Export settings, when you are exporting the model:
If you project is georeferenced, there could be also Projected output option to choose
wasn’t georeferenced… but if i put a grid plane, the export was wrong.
i think that is a problem with a blocked prior pose with laser scanner… but i had follow your advice, to locked pose at laser scanner…
It is not problem with locked pose. It depends, how your project and output coordinate system is set in Application settings and how the laser scans were imported into RealityCapture.
What do you mean by original point cloud?
What do you mean by original point cloud?
-the point cloud alligned in another software
I cechked and the project was wgs, now i put in local1
and i have to export in grid plane? or xmp? what is xmp?
thanks
If it is not georeferenced, then there could be differences between different softs, as the origin can be set differently.
It depends, what you want to export. Both are internal RealityCapture’s coordinate systems (grid plane you can see in 3D view)
XMP system is slightly different to a grid plane, it is related with cameras. RealityCapture defines a series of XML tags which naturally extend the Extended metadata format (XMP) with information like camera pose, orientation, calibration information, priors and more. Vice versa, providing these data, the application can read them and use them as constraints for geo-referencing - or more precisely - fixing the coordinate system.
XMPs allow setting a camera pose directly and thus define the coordinate system:
- define the camera position,
- define the camera position and orientation,
- define the relative or absolute position of cameras.
This opens a way for industrial business cases where the same camera setup is used over and over again and you want to ensure that the resulting scan will stay in the same coordinates.
Ah ok. thanks for information…
but i have tested with a both oprions in local1 and the model was shifted…
i don’t know why
if i use a cloud compare for allign in to my local system (pointcloud original allignemnt coordinate) the model generate, and i copy the rototraslation matrix, can i import in reality? or copy the parameters?
Yes, you can use these parameters in export mesh settings:
and you know how?
this is a matrix of cloudcompare
This part is rotation matrix, you need to compute rotation angles form it. It is possible to do here: https://www.andre-gaschler.com/rotationconverter/
But CC could have different axis (where they are pointing) than RC, so you will need to find the right rotations.
This part should be translation in the axis
Or you can try to export some point from your original model, use them as GCPs in RealityCapture and update the model to this points. Then the models should be in the same coordinate system
This is a CC replay
im solved…
cechk the image