I imported a the duck model from here:
https://github.com/mrdoob/three.js/tree/master/examples/models/gltf/Duck
It looks great when I place it in my scene it, but when I did a .clone() on it, it got all fuzzy.
I tried various "deep cloning" routines and either got errors or it just didn't make a difference. (I left the cloning code in my fiddle, it's commented out, but you can see what I tried.)
Here's the fiddle:
https://jsfiddle.net/gilomer88/w459L7kx/69/
(Attempts at deep-cloning are on lines 186-194)
Turns out the tutorial I was using made no mention of having to set the render's SIZE... once you do that, everything works out and looks the way it should.
Voila.
Related
I have been able to get almost everything I need into the editor, But cannot figure out how to get a collada model that was imported to play it's keyframes.
Since I am not doing loader.load (collada) blah blah like in the examples. I cannot figure out how to get the animations. Animations is always undefined, but I know keyframes exist. Any ideas?
as far as i know, animations in the editor are not fully implemented yet.
the corresponding code in the viewport is commented out (line564+)
i think your best shot is to modify the editor (and eventually create a PR) or go back to coding everything.
the editor in its current form only shows the basic functions but the code is quite well structured to allow implementing custom features.
A quick update that animations in the Three.js Editor are now supported. Below is a gif from the linked PR demonstrating usage.
I am using r82.
I have a mesh with multiple materials. I can change their opacity just fine, but how they are rendered is what I would call "splotchy". I have been using ThreeJs for a while, and EDIT: was able to get the transparency working in a past version (r67) with the same model in a significantly more consistent way. So I was wondering if there is something that now I need to set that I didn't need to set before or if I am just overlooking something. Upon revisiting my older code and testing it again, I found that the same transparency issues were present. It was simply a matter of there not being as obvious "splotches" (and not testing enough, I'm sure). Here is a screenshot.
Here are a few more pictures I took that highlight the issue a bit better. I have the outside wall in a light grey and the floors a dark grey in the model and can toggle the outside walls to be visible or not. In these pictures I have one face of the outside wall purple and a face of the floor in the room on the other side of the wall green.
Based on the angle of the camera, it makes part of the green floor face invisible even though there is only one face between the camera and it.
The materials are all double sided already and there is no sign of this until the transparency is on. I found a similar question that suggested changing the mesh.setFaceCulling (or something similar) but that seemed to be from an older version and wasn't in r82.
Thanks for any help in advance!
EDIT:
I started looking into the old version of threeJS and the current version's source code to see what is done differently regarding transparency. I found transparentObjects, which is an array of the objects (I believe faces) that are going to be rendered and are in sorted based on "reversePainterSortStable". There is another list of objects (I believe for the materials objects, maybe?) called opaqueObjects that uses "painterSortStable". So to see if changing the sort order would change the outcome of how things are looking when transparent I changed it so that transparentObjects got sorted by "painterSortStable" and it did change how things showed up significantly (granted it didn't fix my problem since it just removed some problem spots and created new ones).
So the short version, it looks like it is an issue with the renderOrder of the faces.
That being said, I tried finding how the r67 version of the code handled the "renderOrder" of the faces since it wasn't something that (to my knowledge) could be set in that version and just did it automatically. But I have had no such luck tracking down how it was done as of yet.
So I see two possibilities. 1) find out how the past version correctly did transparency (at least for my purposes) and change the logic in the current version to use that. Or 2) find how to properly set the renderOrder of the faces based on the camera position in the scene. Will look into the second option first, but figured it would be good to document this for others looking to help answer or that have a similar problem.
EDIT 2:
So digging through the source code for threeJs and noticed something about the transparentObjects array I mentioned in the previous edit. The first, that I cannot for the life of me figure out how it gets populated since it doesn't seem like it is added to anywhere in the code. The second is that I think it is being populated with duplicates of the entire building object/mesh (see screenshot below).
The z indexes all seem to be the same. as well as the ids and the objects are all of type "mesh" (of the ones I looked through, granted, since there are a few thousand). So I was going to figure out why its adding what is being added to the array, but that is when I stumbled across the issue of not finding where in the code that the transparentObjects array actually get populated.
EDIT 3:
WestLangley, I tried setting the depth test for the outer wall material to false and got this. Like I said in my response comment, even if it did work it wouldn't fix the issues experienced with the camera inside the building, but wanted to follow up none the less (see snapshot below).
When displaying a box graph, pygal displays values outside of the normal zones. You can see the example on their site as well:
You'll notice that no values are above 16,000 or below -4000 (in fact none are below 0). It just doesn't display properly.
This is posted for anyone who doesn't look on the website for answers (which I don't usually).
There is a solution to this problem, and it is not resolved completely yet - but there is a quick fix.
In the meantime, to make it work (as expected) instantiate the object like this:
box_plot = pygal.Box(mode='extremes')
You'll notice that the above example will be solved, and in fact to my knowledge this is the only way to make box plots work.
To follow the issue: Link to the issue request
three.js comes with many useful controls, which cause camera movement in response to keyboard and mouse input.
They are all at https://github.com/mrdoob/three.js/blob/master/examples/js/controls and accessed in the code as e.g.THREE.OrbitControls .
However, I can't find any documentation or comments that says what situation to use what control for or what they are intended to do.
Can anyone point me to this information, or do I have to analyze the code to figure out if, for example, I prefer FlyControls to FirstPersonControls?
The documentation for the controls does exist, but it was deleted from the repository here. Seems like a bizarre thing to do, but there is an explanation of sorts here. I guess the docs were very incomplete anyway and it was easier to delete them than to finish them. :-p
The source code for most of the controls contains pretty decent comments. I know this isnt as good as proper documentation but it really helps to get a handle on how to set up the controls
The Controls are named by their purpose or the idea they implement. OrbitControls allow you to orbit around some kind of object. Same for Trackball-Controls although the trackball-scheme implies that the camera will rotate around without the up-Axis staying as it was like in orbit-controls. Fly and FPS-Controls are self-explanatory.
Just try the examples and you will see what the difference is. No need to analyse code. Just depends on what you want to achieve.
I have some JSON files that define geometries, as required by r42 of Three.js's JSONLoader class. The files are version 2 of the format.
Is it feasible to manually update these files between versions?
The first obvious difference is that the file is no longer JavaScript, but actual JSON. This was easy to correct for. However the new format has a metadata section, and thirty minutes of experimentation with is isn't getting me anywhere.
I'm seeing problems because the Geometry object's material properties has an empty materials array. The resulting geometry has multiple parts with different materials, as seen in r42.
Does anyone know how I might manually tweak these .json files to work with r55?
I have no complete knowledge how the internals of the format have changed, but here's a couple of hints:
If you have the source object, the best way would be to re-export/convert. There should now also be more converters and exporters to use if your source format is obscure. If the source is unknown, some Googling might be worth it.
metadata section doesn't matter, it isn't used for anything in the loader.
There is no more Geometry.materials. Instead, JSONLoader's callback returns the loaded materials as a separate parameter to the callback. See Migration Guide (r52->r53) for more on that. In fact, the loader interface has changed also in r46.
git log of some example model files (searching for changes there could be your way forward if you really need to manually migrate) suggests that there might be e.g. UV flipping which would be difficult to fix manually but could be worked around in code. But first you'd need to get something to display on screen.
Try dragging the file into the editor, then do File/Export Geometry.
Here is a fix for drag and drop into the editor. Add this code before the drop event in index.html. I tested this in Chrome ( 24.0.1312.56 ), Safari and Firefox in OSX.
document.addEventListener("dragover", function(e) {
e.preventDefault();
});
#mrdoob's answer worked after a few patches to the editor (here and here.)
However it's worth noting that upgrading the files by hand in a text editor is possible, especially if you don't have any UV coords.
Earlier versions did not use JSON -- they were JavaScript files. The conversion is straightforward.
You can either ignore the metadata section, or else port it from the comments into an object.
If you do have UV coords, then they must be mapped differently (I believe an axis is flipped)