I'm simply trying to add a model with a diffuse and bump texture to a simple scene in react 3 fiber.
I have literally no clue what I'm doing wrong.
Heres the sandbox: https://codesandbox.io/s/three-point-lighting-in-react-three-fiber-forked-qeqlx?file=/src/index.js
The model is a GLTF moon, that has the textures baked in. The moon is just a sphere but I want to use the GLTF model. Currently, the scene displays the background and lights, but no model.
If you have any insight about this I would appreciate it immensely!
At first glance, it looks like you're importing GLTFLoader and moon, but you're never using them. That's what those squiggly yellow lines mean:
Make sure you implement them as outlined in the documents:
const loader = new GLTFLoader();
loader.load(
moon,
function(gltf) {
scene.add(gltf.scene);
}
);
Alright, I figured it out. Thanks to #Marquizzo
Issues:
The .gltf file was not in the correct directory. It needed to be in the public directory since I am using the "npx #react-three/gltfjsx" script.
The .gltf was incredibly large relative to the scene. In Cinema 4d, it is perfectly sized. But in three.js, it was around 99x too large.
The position of the mesh was behind the camera. I had no clue that you could use Orbital Controls to move the camera around and manually find the object. I also positioned the object at [0,0,0].
The template scene I was using was from a tutorial from almost a year ago. So there had been some major developments since then that caused simple bugs on runtime. So I updated the dependencies.
Issues I still have:
Textures aren't loading from the baked-in .gltf file.
I increased the lighting and it seems that the lighting isnt the issue.
Heres the fixed sandbox: fixed
What I learned:
Orbital Controls
Use of OBJLoader
useHelpers like CameraHelper
Related
I loaded a Mesh from a JSON File, here is my current result:
my Project
It is an object I exported from blender as JSON and then used its vertices to create a geometry of Points (THREE.Points) (which is important for the looks of it)
I am now looking for a way to "animate" the Points, so that the "surface" looks vivid / living. So basically it should be moving around a bit, something like this (without the rotation):
Link to animated Gif
I have ruled out displacementMap, as this does not work for the PointsMaterial (or does someone know a workaround?)
Does anyone have hints or ideas? I thought of maybe morphing 2-3 Objects .. but I am not sure if this will work for a points mesh.
One approach to achieve your desired effect is to use morph target animation (also called vertex morphing). As you can see at the following example, three.js does support morph target animations with points.
https://threejs.org/examples/webgl_morphtargets_sphere.html
There is a lot of existing literature about vertex morphing, so it should be no problem to get familiar with this technique. I suggest you create your animations in Blender, export the model to glTF and the load the file via GLTFLoader into your app like shown in the example.
I'm using BabylonJS V3 with Blender 2.79 to create product visualizations. Many times, it is necessary to define more complex shaders in the JS code. I'm using lines like
scene.meshes[1].material.emissiveColor = new BABYLON.Color3(1, 0, 0);
to define the shaders after export. Usually every mesh can get it's own shader this way. Unfortunately in one case, the shader of multiple meshes is overwritten. Did someone have a similar problem?
All meshes are named individually, they all have a basic (individual) shader from blender. They don't share any datablocks, no instancing or duplication was done. I'm thankful for every hint.
Edit
It seems, the error occurs with the new version (3.0), updating to 3.1 fixes the problem, but introduces errors with the arc-rotate camera. As soon as you click on the canvas, to rotate the view, you can't release the mouse anymore. Are the latest stable releases buggy?
Edit 2
After some in depth trouble shooting we came to the conclusion, that the 3.0 and 3.1 versions and/or their exporter plugins are faulty. Even in the simplest testscenes, this error occurs. Alongside other problems, like broken cameras and displaced geometry.
Be aware that by default materials are shared for performance reason. So this is probably not a bug but a feature.
If you want to change the material for a single mesh you will first need to clone it
I am trying to add a skybox to a model in Forge Viewer.
So far I have managed to create and add the skybox to the model via an extension.
The problem is that the skybox needs to be big, and the camera back clip plane will be to short; - eg. the skybox is only partially visible or hidden.
I did not manage to modify the camera settings to change the clip plane and was therefore thinking of another way:
I was wondering if it was better to keep the skybox in a separate ThreeJS Scene, but so far I am not able to figure out how the extra scene should be added to Autodesks Viewer3D, neither how it should be kept in sync with the main cameras rotation.
Any pointers and examples would be appreciated
Loading an extra scene can be an overkill to achieve such feature, the easiest workaround would be load a second model that has a slightly larger extends than your skybox, so the viewer will automatically update its clippings plane.
What I suggest you to do is to translate a model that contains only tiny spheres or cubes defining the desired extends of the skybox scene. Then you will load that model either using its urn or downloading its resources and loading it "Local" even if your other model is loaded from the cloud.
See there for more details about extracting viewable resources and running Local vs cloud based:
https://extract.autodesk.io
Working seamlessly online/offline when developing your Web applications with the Forge Viewer
Hope that helps
When I export an animated skinned mesh from Maya using the Three.js exporter, it always appears to have a duplicate mesh combined with it that is not animated.
I've tried all the export settings I can think of and also made sure there is not another mesh being exported with it. I can reproduce the problem by skinning, animating, and exporting any mesh.
I compared my exported .js file and I can't see any difference between that file and this working three.js example:
http://threejs.org/examples/#webgl_skinning_simple
This problem does not exist using a previous release of Three.js (r73).
There appears to be a bug in r74 and r75.
I'm working on porting an existing three.js project to WebVR + Oculus Rift. Basically, this app takes an STL file as input, creates a THREE.Mesh based on it and renders it on an empty scene. I managed to make it work in Firefox Nightly with VREffect plugin to three.js and VRControls. A problem I have is models rendered in VR aren't really 3D. Namely, when I move the HMD back and forth an active 3D model doesn't get closer/farther, and I can't see different sides of the model. It looks like the model is rather a flat background image stuck to its position. If I add THREE.AxisHelper to the scene, it is transformed correctly when HMD is moved.
Originally, THREE.OrbitControls were used in the app and models were rotated and moved properly.
There's quite some amount of source code so I'll post some snippets on demand.
It turned out that technically there was no problem. The issue was essentially with different scales of my models and Oculus movements. When VRControls is used with default settings, it reports a position of HMD as it reads it from Oculus, in meters. So, the range of movements of my head could barely exceed 1 m, whereas average sizes of my models are about a few dozens of their own units. When I used them altogether at the same scene, it was like a viewer is an ant looking at a giant model. Naturally, the ant have to walk a while to see another side of the model. That's why it seemed like not a 3D body.
Fortunately, there's a scale property of VRControls that should be used for adjusting scale of HMD movements. When I set it to about 30, everything works pretty well.
Thanks to #brianpeiris's comment, I decided to check coordinates of the model and camera once again to make sure they're not knit with each other. And, it led me to the solution.