I've loaded a model into my scene (.scn) and when zero-ing the model out, it seems to be at a 90 degree angle on the x-axis (even though the inspector says 0).
This is incorrect, but strangely when the running the scene on the emulator the model loads in the correct position.
Has anyone experienced this before? It's rather annoying.
Yes! This is a common thing to experience.
Depending on where you made your model, blender, sketchup, 3dsmax, etc.
Some programs use a "Y-up Axis" that means that the Y axis is up. However, SceneKit uses a "Z-up Axis".
The reason it appears differently when running your app is because in your ".xcaccets" folder, or whatever it is called, you have "always convert to z-up axis" checked.
I'm not quite sure how to convert it before editing in Xcode's editor, but perhaps, you could use write(to:options:delegate:progressHandler:) to export the corrected version out of SceneKit for non-eye-sore Z-up editing.
Hope This helps!
Related
I'm just starting out in ARjs myself. I found an issue that I'm confused on how to solve. My gltf model won't show unless it's on scale 5x and it only showed partially as in the left top corner on the actual model. My assumption is from the position, but I'm not sure how to approach this?
I already saw the https://github.com/jeromeetienne/AR.js/issues/299 thread solution, but it didn't work.
You didn't share your code so it's really hard to know what is the problem there. From what you are describing I would try scaling your object down and not up. If you only see small parts of it on a 5x scale, I guess you were inside the object this entire time. Try scaling it down to ~0.1 and see if it works. Also, make sure your model is positioned to 0,0,0 (or just don't specify the position at all ass this is the default). Another thing I think you should try is our platform echoAR. You can upload your models and easily have an ARjs experience. Just follow the docs.
I am working on a project that will display objects below the ground using AR Quick Look. However, the AR mode seems to bring everything above the ground based on the bounding box of the objects in the scene.
I have tried using the USDZ directly and composing a simple scene in Reality Composer with the object or with a simple cube with the exact same result. AR preview mode in Reality Composer is showing the object below the ground or below an image anchor correctly. However, if I export the scene as a .reality file and open it in using AR Quick Look, it brings the object above the ground as well.
Is there a way to achieve showing an object below the detected horizontal plane or image (horizontal) using AR Quick Look?
This is still an issue a year later. I have submitted feedback to Apple. I suggest you do too. I have suggested adding a checkbox to keep Y axis persistent. My assumption is this behaves this way to prevent the object from colliding with the ground, but I don't think it's necessary. It's just a limitation right now.
In Xcode, I have a .SCN file that was transformed from a .DAE file. I've worked with the person who made the model to set all of the Physically Based (PBR) settings. But no matter what I do, the preview is always black.
Also, if I change the environment to Procedural Sky the model will also display as black.
I'm aware that adding a light to the scene will "fix" this, but should I have to do that? Since it gives my models unrealistic shadows?
I changed the Illumination settings to be the _m file in my list of textures. I suppose this has something to do with the way the model interacts with the light in the scene.
I just rebuilt my lights, i.e. I had 4 directional lights, so I made a new directional light to replace the first one, manually copied all of the settings including of course the rotation settings, deleted the one I copied from, made a second directional light, copied settings from the second one, etc. I think the problem started for me because I was copying lights from other .scn files, and something between the lights and the PBR materials is getting disconnected.
EDIT: Ok I just realized that rebuilding isn't necessary - the lights were within a group, which is how I copied them over to this scene. I just grabbed all the lights in the group and moved them out of that group and magically they all started working for the PBR materials again. It's a Christmas miracle.
With AIR 24 release we are able to set anti aliasing on Stage3D now, but there are some issues with it. Can anybody help how to use it in right way without changing entire project code ?
The issue I have is that anti alias works great, and no more jagged edges, but there are rendering issues and I guess some texture normals are being inverted, also when using Occlusion Material there are some jagged material shadows...
Next thing I notice is when drawing Wireframe Globe with Lines Segments - the lines are visible on the globe all the time, no matter if you add some object in front or not.
So, intersecting line segments with other materials don't work at all, and lines are on the screen forever.
Please, help if you find any trick fixing the issues.
Thanks
Just to add some more information: the issue seems to happen when shareContext = true. Without Starling there is antialiasing and the lineSegments are rendered at the current depth. It would be interesting to see if it works with other sharedContext besides Starling to isolate the issue. If I find an answer I will come back and post it. It would be nice to get this working. Any idea the performance hit on mobile of having a second instance of away3d? Layering that way might be a dirty work around.
*****EDIT****
AntiAliasing on the line Segments only occurs with sharedContext. View3D class does not seem to have it's antiAlias value set anywhere and when I forced it to a value of 2, all hell broke loose.
Edit#2
Mesh appears above line segments, Sprite3D do not.
I have a similar issue as in this post, using the same model, also loaded with the Collada loader.
The windows of the car are not displayed as transparent in three.js. You cannot see through them.
After digging through the three.js object data structures, it looks like the material for the window has opacity = 1 and transparent = false set on it.
I tried both with the release and with the dev version of three.js, as advised in the above referenced post but without any luck.
I also tried setting the opacity to 0.3 and transparent to true by hand in the material object (in debugger) and the transparency appears ! (although with some flickering).
Any idea what is wrong ? Is it a Collada loader problem ?
UPDATE: same problem on a much simpler model:
screenshot of the problem
link to the SketchUp model
Thank you
Martin
I just tried this and it's working for me. I took the model from open3dhub and imported it into ThreeFab and then exported it to a jsfiddle(source). I still see the flickering (that's a separate problem). This is on three.js from master.
I still do not know if this is a ColladaLoader bug, a SketchUp issue or a bizarre feature of the Collada spec but I found an easy enough workaround:
Edit the Collada file by hand, find the tag and set its value by hand to 0.3 or anything you want instead of 1.
Not perfect but workable.