Three.js calling clipAction.play() makes animated objects vanish - three.js

In Three.js, Calling action.play() makes objects just vanish, without any error or warning on the console.
I use THREE.ObjectLoader to load a JSON file created in blender. The srt (position/scale/quaternion) animation is in the generated file. As are the morphtargets. To optimise filesize I animated the srt as a series of null objects. The morphtargets tracks are in the main object, which I clone 5 times to build the characters (balloons to be exact).
I previously did extensive testing to introduce shape/morph animation. After being succesfull I finalised all the animations. Only to be trumped by the disappearing models. The srt (position/scale/quaternion) animation was working fine before. But after refactoring the code, to be less spagettied, upon calling action.play(). The objects just vanish, exactly then. Echoeing the mixers and the array containing the clips, everything looks correct (ie I see the tracks, the names are right etc). Also examining the newly generated JSON, it seems the same and correct (also I have not changed the SRT animations, only introduced shapeanimation)
So I am lost, and think this looks more and more like a bug. From previous experience I do know it works (or has worked).
I created a jsfiddle: https://jsfiddle.net/oompol/3ya6sqed/
[edit] I turned on the action.play and call the function from the link in the div [/edit] please note I commented out calling action.play(). So you see the load and init work. See the function listed below
function playScene(scene) {
for (parentName in srtMixers) {
var clpName = "balloon1_fly";
var clp = THREE.AnimationClip.findByName(animLib, clpName);
var action = srtMixers[parentName].clipAction(clp);
action.clampWhenFinished = true;
console.log("playScene:", clpName, clp, parentName, srtMixers);
//this is when the problem happens
action.play();
}
}
This is the JSON I am loading:
https://rawgit.com/bakajin/2e3d2f6a722103ed4aefd76f6250ec08/raw/28cad35c20060d478499c0cd40a2753611993720/oomp-scene_balloons-oomp-6.9.4.json

Ok,
there was something very wrong with the scaling indeed.
The io_three JSON exporter for Blender (r87 dev) writes incorrect matrix transformation data in the geometry object (really tiny scaling values). The animation track with the scaling keys were correctly written as 1,1,1. So all the objects just scaled out of view immediately.
Hard to see because the geometry has no separate scaling value but a matrix. Seems to happen when you set "Scene" to true on export.
Worked around the problem by entering the scaling value in the keyframe tracks. But this will only work if you have no scaling animation (so the keys are all one).
Meanwhile I have extensively edited the JSON by hand. Because this is not the only incorrect data. The formatting of the animation object is also wrong. The durations for the morphTargetInfluence Keys is also incorrect. The formatting of these keys is also not always correct.
Hope this helps some other ppl

Related

3D model scn file does not rotate or scale in AR kit

I started a new Xcode project with the ARKit template and simply replaced the "ship.scn" with my "test.scn" filename asset. The object is about 16.5mm wide and 4.8mm tall. The ship worked fine of course, but my test object that reads "test" does not rotate as I move around it, or scale when I move towards or away from it, yet it does track in one location.
I compared the ship and test attribute panels, and I can't find anything that is different about them, except that the ship is textured and my test text is not. What is inherently special about scn objects that would make them behave correctly in ARKit besides their size? I've read through the documentation about anchoring, but it seems like I wouldn't have to do this in code if it's already a scn object.
In case anyone wants to test the file I'm using in the ARKit template to see how it's behaving, the file is here: https://ufile.io/ey49t
I’m answering the question because I think it could help others that are making a similar mistake, but it can be closed if it doesn’t make sense.
The problem is that the size was much too large where I could not see scaling or rotation no matter how much I moved around the room. Compare the scaled size in the last attribute panel on the ship model - not its actual size. Then get the size of your own model scaled down enough so that it is actually resonable.

Fabric.js doesn't maintain group when exporting/importing JSON

So I have another issue with Fabric.js that's once again probably down to my own ignorance.
Imagine using free draw to scribble some line paths on to a canvas. When finished, we disable free draw and at this point I want to take all the objects drawn and group them in to a single entity.
I've created a fiddle here that shows the grouping stage.
var grp=new fabric.Group();
canvas.getObjects().map(function(o){
if(o.type=="path"){
o.hasControls=o.hasBorders=false;
grp.addWithUpdate(o);
//canvas.clear(); // this seems to break grouping
}
});
canvas.add(grp);
canvas._activeObject = null;
canvas.setActiveGroup(grp.setCoords()).renderAll();
This appears to work well enough (even if the paths themselves appear to darken once the group has been created).
I now want to export this to JSON, save at a DB, and in the future reload and replicate the whole layout.
In the fiddle above I reproduce this sort of behaviour by first saving the canvas to JSON after the group has been created, and then attempt to reload it.
As you'll see, the reload itself works fine and the positioning is good but the item that was previously grouped has been loaded in to it's constituent parts, rather than being maintained as a group.
Am I doing something dumb here?
Thanks for any help!

Three.js - Under what conditions are THREE.Lines frustum-culled?

I'm drawing a handful of lines (THREE.Line). Under some conditions, the line suddenly disappears from the screen. This happens frequently when one endpoint is far outside the camera's field of view, but the other one is definitely within the field of view. This also happens when the line crosses the camera's field of view, but both endpoints are far outside it.
I can temporarily fix it by setting frustumCulled to false for each line, but this isn't optimal since I might have thousands of lines in the scene.
Is this working as expected?
BTW, I'm using r68. I haven't had time to refactor my app to work with r69. I'm using the WebGLRenderer.
I needed avoiding lines to dissapear too.
Following Justin idea of frustumCulled I had to do
line.frustumCulled = false;
I thought it was
line.geometry.frustumCulled = false;
but I was wrong, you've to apply it on the line not on its geometry.
This works for me on version 0.70

Manually upgrading Three.js JSON geometry files from r42 to r55

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)

iPhone iOS5 querying OpenGL ES 2.0 pipeline objects if they are hidden in the view or not..."Occlusion"

EXT_occlusion_query_boolean is new with OS5.0,
it looks to me like not a single person on the entire internet has posted about these new extensions nor used this code....
so here they are set up properly...which is not documented anywhere as far as i can tell... you can imagine how they would go in your code from this little sudo code here:
import UIKit/UIKit.h
import GLKit/GLKit.h
import "GLProgram.h"
GLuint testBox,hasBeenTested,theParams;
//...
glGenQueriesEXT(1, &testBox);
glBeginQueryEXT(GL_ANY_SAMPLES_PASSED_EXT, testBox);
//... draw an object .......
glEndQueryEXT(GL_ANY_SAMPLES_PASSED_EXT);
glGetQueryObjectuivEXT(testBox, GL_QUERY_RESULT_AVAILABLE_EXT, &hasBeenTested);
if (hasBeenTested) glGetQueryObjectuivEXT(testBox, GL_QUERY_RESULT_EXT, &theParams);
glDeleteQueriesEXT(1, &testBox);
if (!theParams) object is hidden; don't draw next time;
hopefully some here can use this code, i've tested it and it works,
however, there appears to be a bug in GLKit, where if you use self.effect2 = [[GLKBaseEffect alloc] init]; type of GLKit code to render an object, rather than a normal GLES2.0 pipeline, the queries will fail to give you the correct answer... (never hidden) although i tested a pipeline object hiding a GLKBaseEffect object, (which fails) so it could be there is a bug just mixing the two types, if you go the other way, have a GLKBaseEffect object hide a pipeline object, it gives the correct answer, i did not test further yet.
so the question is, I bet i can go further with this and create collision detection in the vertex/fragment shader somehow... this code i found looks like a start... given these two pieces of sudo code, can someone get me closer to collision detection that just triggers when a "part" goes completely inside another part? a quicker easier/firststep could be to have the entire object hidden inside another object before a positive is triggered, this would be a great start, any ideas?
http://ucv.academia.edu/RhadamésCarmona/Papers/743483/Volume-Surface_Collision_Detection

Resources