THREE.EffectComposer in A-Frame - three.js

Anyone has a good example on how to use THREE.EffectComposer correctly in A-Frame? Especially the combination of EffectComposer and PMRemGenerator.
Used https://gist.github.com/donmccurdy/31560945d5723737e6c656a2974ab628 for now, but this method breaks a couple of things. The inspector, but more importantly the use of PMRemGenerator for example. (It also doesn't work in VR, but that's minor for my specific project)
And https://github.com/wizgrav/aframe-effects doesn't work on recent versions anymore, and doesn't seem to be maintained anymore. (And I'm too much of a newbie to try and fix that I'm afraid) (edited)
UPDATE: Edited the original question to make it clear the combination PMRemGenerator / EffectComposer is the important part. VR not so much, but that wasn't clear in the original form.

Not possible. VR post-processing depends on on-going THREE work that you can follow on this PR: https://github.com/mrdoob/three.js/pull/15840

Related

Three JS animation in Editor possible?

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.

Inconsistent transparency, looking like render order issue

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).

Documentation for three.js controls?

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.

How to save the content of a ID2D1RenderTarget to a file

I have an existing component that draws Direct2D content to an ID2D1RenderTarget and I would like to save that drawing to an image file. The questions here, here and here, although they helped me, did not provide a clear answer as how to do it.
My nullth idea was to try the official MSDN method. Unfortunately, it is not available in Win7.
My first idea was to modify the drawing routine to make it accept the RenderTarget as a parameter and use ID2D1Factory::CreateWicBitmapRenderTarget to draw directly into a IWICBitmap, but it turns out to be quite difficult for me (because it would be necessary to modify not only the drawing routine itself, but also the drawing callbacks of all users of that component (the code, written in Delphi, uses Embarcadero's TDirect2DCanvas, and thus did not need to manage all Direct2D resources, like render target or brushes)).
My second idea was to create an ID2D1Bitmap, fill it with what is already drawn using ID2D1Bitmap::CopyFromRenderTarget and then draw that ID2D1Bitmap to a WicBitmapRenderTarget (this is about what was done here). I had the same kind of problems as those who asked the questions I link to: different resources affinities, as briefly explained Kenny Kerr.
So is it possible under Win7 without having to implement my first idea, and how would you do it?
Direct2D 1.1 is supported on Windows 7 if you install the Platform Update. Unfortunately, that doesn't solve your problem without first creating two more of them: 1) it's still pre-release/beta, and 2) it adds another installation dependency for you to worry about.

Has anyone ported globe (the chrome experiment) to the latest threejs version?

Short story:
The globe code is based (and contains) threejs v40 while the latest version in github is threejs r55 at the moment. I was wondering if anybody (more knowledgeable then me in this area) has ported globe to a newer threejs version?
Long story:
I was fiddling around with googles globe from http://www.chromeexperiments.com/globe.
I noticed that it is based on an old threejs (on github) version. Using the latest version (and getting the same results!) did not prove to be easy. Also see this question.
I changed around some function names and fumbled some parameters, no big deal. Then I turned to the shaders. That proved to be more challenging. The old version of threejs seems to have a bug when you do Mesh.flipSided = true;: the normal vectors seem to be different in the shaders between old and new version. But the shader code in globe was written towards this bug, so I had to correct the shader code.
I now have something that sort of looks the same, but combining the atmosphere and the earth is not working at all. I am suspecting this threejs bug to play a part in it, but I am not sure. Again this is a flipSided bug that might have been used by the globe authors.
Well, ehm, I am sort of stuck here. I can do what I wanted to do sticking with the old version, but that somehow feels bad.
Can anyone shed some light here?
According to the changelog at https://code.google.com/p/webgl-globe/source/browse/globe/globe.js :
"Nov 5, 2012. Updated to threejs r52 and tweenjs r7."
So, on the surface it sounds like it has been updated... which parts of the code specifically are giving you trouble?
Nowadays, instead of Mesh.flipSided = true, in the material of the mesh, you need to set side:THREE.BackSide instead.
Can you post or send a link to your code for further investigation? An updated version of the globe project sounds like a most worthy endeavor.

Resources