A cubic envMap seems to skip the first object it's applied to. Subsequent objects referencing the same map are fine. Reordering the objects in the HTML still results in which ever is first being skipped. Reordering in space has no effect.
https://github.com/scottmsinger/aframe/tree/master/tests/env_map_order
Your cubemap tag is missing a close tag. That might be messing with the interpretation of the nextmost tag, causing the issue.
<a-assets>
<a-cubemap id="sky">
...
</a-cubemap> <-- Make sure to add this tag
</a-assets>
If your html/xml editor of choice didn't warn you about this, I'd advice you to switch to a different editor, as it will save you a lot of debugging time. Even quick online tools like JSFiddle highlight XML tag mismatches.
Related
Hello everyone so I've been trying to render a book page that is attached to your hand in VR (testing on oculus-go) using A-FRAME. Initially I tried using a plane and applying the text to it using the text attribute and then defining its value, alignment, font etc... Everything worked fine enough however the text gets "jagged edges" that seem to get worse the more you move your hand (which is basically impossible to not do) making it extremely bad for a long text-form such as a book page.
Then I tried exploring an alternative by using the aframe-html-shader by mayognaise. By creating an html div and using css it's the perfect solution in terms of customization, alignment and etc and when I render it, the text doesn't get any "jagged edges" anymore (since it's basically a texture).
However, it gets blurry enough that it becomes tiresome for long reads.
I've tried everything I could to increase its sharpness however it keeps being blurry which makes absolutely no sense to me.
What I've tried:
Increasing the size of the object the texture applies to and then scaling it back after the render - result: same thing...
Increasing the size of the canvas or the texture inside the aframe-html-shader.js - result: the same thing... however some of the tinkering attempts seem to trigger a "image too big (...) scaling down to 4000" (4000 something I don't recall the exact value) which seem to indicate the canvas is already being rendered at full resolution
Switching from Mayognaise aframe-html-shader.js to wildlifela fork (which already has an option of "scale" on the shader) and applying "canvasScale: 2" - result: same thing...
Using a 4000px width html element as the object to render from, increasing the font accordingly- result: same thing...
I'm out of ideas and really don't understand why I can't get good enough text out of the html shader since if the text is within an image and I use that same image as a texture, the text comes out perfectly readable.
Need some help from all the A-Frame experts and developers over here!
Thank you all in advance!
Increasing the size of the canvas or the texture inside the aframe-html-shader.js - result: the same thing... however some of the tinkering attempts seem to trigger a "image too big (...) scaling down to 4000" (4000 something I don't recall the exact value) which seem to indicate the canvas is already being rendered at full resolution
It wasn't too big. This is because textures needs to be a power of two size (e.g., 4096x4096).
The standard text component should be clearest though. A-Frame master branch has a fix to make text look clearer, might help. https://github.com/aframevr/aframe/commit/8d3f32b93633e82025b4061deb148059757a4a0f
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).
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)
The IE9 layout engine has issues with tables. Whitespace seems at the root of it.
If you've seen the infamous ghost cell you know what I'm talking about, if you haven't, consider yourself lucky and don't worry about it.
Anyways, I'd really like an HTML only sample to test "fixes" on.
I know I've seen it before in odd circumstances several layout tables deep, but I can no longer get the ghost cell to come up when I need it to.
What I need is a consistent ghost cell without invoking JS.
I've found several JS related ones, and there are plenty discussion on those when it comes to sorting.
This is a great sample:
http://www.ncf.ca/ncf/support/ie9_issue/index.html
Some discussions:
http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/28d78780-c95c-4c35-9695-237ebb912d90
http://datatables.net/forums/discussion/5481/bug-ghost-columns-when-generating-large-tables/p1
http://datatables.net/forums/discussion/8248/datatable-in-ie-9-bug-with-large-tables/p1
I managed to clean up the html quite well and still keep the issue. I replaced all the javascript with equivalent spaces & newlines, and could remove most of the elements attributes without affecting the ghost-cell.
It seems like IE has a buffer problem since removing single spaces or newlines in a "safe area" cause the ghost cell to disappear, while removing entire attributes does not affect the rendering.
I see that you have unclosed tags, but I also managed to remove them altogether (replacing with spaces) without removing the ghost cell.
Result being I have a javascript-free html with ghost-cell. See result here: http://compscicon.no/ghostcell.htm