I'm working on a very simple a-frame webvr scene. I want to create an <a-sphere> that when interacted with will scale in size to mimic that of an <a-sky> component in that it will have a 360 photo material mapped to the inside.
Currently I have tried just starting with a small sky and scaling it up:
<a-sky color="#000" scale="1 1 -1" radius="1">
<a-animation attribute="scale" dur="10000" begin="500" to="1000 1000 -1"></a-animation>
</a-sky>
I'm curious about how to best approach this, currently when I animate an increase in the scale the sphere expands but only fills up half of the world view and doesn't encapsulate the player. I believe this is because the initial radius is set to 1. Should I be scaling the radius instead of the scale? or should I write a custom sphere component and avoid using <a-sky>?
Scaling the Z axis as well works for me to="1000 1000 -1000"
http://codepen.io/team/mozvr/pen/VazpEo?editors=100
A-Frame / https://aframe.io
Related
I have a earth object that I would like to rotate using animation in A-frame.
I just want the object to rotate forever and I don't know how to do it.
Below is my code thanks!
<a-sphere rotation="45 0 0" position="-44.277 50 -80.933" radius="30" src="images/earth.png" roughness="0.6">
<a-animation attribute="rotation"
easing="linear"
dur="10000"
to="0 360 0"
repeat="indefinite">
</a-animation>
</a-sphere>
That code is correct. It will take 10,000 ms (10 seconds) to complete 1 rotation, and it will repeat indefinitely ("forever"). I just tested the code and it works. If the earth.png texture isn't appearing, it may be difficult to see the sphere rotation. If you use the same code on an <a-box>, for example, it's much more obvious.
That said, since you have the rotation for the <a-sphere> set to 45 along the x axis and have the <a-animation> set to rotate to 360 over the y axis, it will not rotate in a linear fashion.
This can be remedied by adding a container <a-entity> element and setting the default position and rotation on that entity, removing it from the <a-sphere>, which will now be positioned relative to its container.
Here is demo: https://codepen.io/dansinni/pen/MVgqxd
Note that I had to use a different texture for the Earth.
I have 10K cubes and the draw calls is very high, well.. 10K
You can see this here:
http://thegrook.com/three.js/merge1.html
If I combine all cubes to a single mesh, the draw calls is down to one.
You can see this here:
http://thegrook.com/three.js/merge2.html
But in the first example, I change the scaling of each cube based on the distance from the camera,
So no matter what is the zoom - the cube staying the same size on screen, and this give me the effect that I need:
The closer the camera is - the lower the density between the cubes
In the second example - this doesn't work, because the scaling affect the whole mesh and not per cube
Any idea how to achieve the density effect with less draw calls?
Thanks.
* Edited 1 *
I managed to solve this with instancing and render 250K objects and stay on 60fps
When I zooming out - the objects are overlapping - that's ok for my case.
But what's wrong is all the textures are flickering a lot..
Seem like there are no fixed drawing order for all the instancing
There is a way to fix this?
Here is an example:
http://thegrook.com/three.js/instancing3.html
* just zoom out with the mouse wheel
* Edited 2 *
Looks like If I disabling the depthWrite on the material - the problem is solved
Is this the right solution?
I need rotate X axis of a-sky in my task in a 360 image liked project, but when I rotated, the look-controls works weird. The reason may be that camera's axis need change, and how can I change that camera's axis ?
look-controls works weird
<a-sky src="#skyTexture" rotation="30 0 0"></a-sky>
I guess you want to change the basis axes of the camera space, the easiest way to do that is wrapping the camera with a rotated object:
<a-entity rotation = "30 0 0">
<a-camera look-controls>
</a-camera>
</a-entity>
But, be careful, if you do that, all the objects in the scene would have a slope.
The controls are okay, You crooked the image, and the horizon is no longer a perfect circle around the camera, so Your perception feels off. If You rotate the camera, You will see the same image as if You didn't change anything.
I made a quick comparison of the rotations:
Take a look what is the relation of the horizon on the image, and the (0,0,0) grid. You can't rotate the sky in x, or z, and expect the guy to be lower and the horizon to be normal. If You want the user to be "higher", change the a-sky to a a-sphere and position it a bit lower than the camera, like i did here: https://codepen.io/gftruj/pen/Kqbxbx.
Craig.Li's anwser is correct if You want to rotate the camera, but its a bad idea to mess with the camera since the user should be the only one manipulating the camera ( what i think the initial intention of a-frame was ).
I have a scene in which I render and tween multiple circles (from 7 up to sometimes 50 circle sprites) in unity, but it's hammering the frame rates on mobile. How can optimize this? Can I cull circles that are fully hidden behind other circles? Is there a circle shader that i can use that's efficient? Can I achieve the same effect differently?
Here's a screenshot of what I'm talking about:
I've got a question about getting sprites to work with three.js using perspective and orthogonal cameras.
I have a building being rendered in one scene. At one location in the scene all of the levels are stacked on top of each other to give a 3D view of the building and an orthogonal camera is being used to view it. In another part of the scene, I have just the selected level of the building being shown and a perspective camera is being used. The screen is divided between the two views. The idea being the user selects a level from the building view and a more detailed map of that selected level is shown on the other part of the screen.
I played around with sprites for a little bit and as far as I understand it; if the sprite is being viewed with a perspective camera then the sprite's scale property is actual it's size property and if a sprite is being viewed with an orthogonal camera the scale property scales the sprite according to the view port.
I placed the sprite where both cameras can see it and this seems to be the case. If I scale the sprite by 0.5, then the sprite takes up half the orthogonal camera's view port and I can't see it with the perspective camera (presumably because for it, the sprite is 0.5px x 0.5px and is either rounded to 0px (not rendered, or 1px, effectively invisible). If I scale the sprite by say 50, the the perspective camera can see it (presumably because it's a 50px x 50px square) and the orthogonal camera is over taken by the sprite (presumably because it's being scaled by 50 times the view port).
Is my understanding correct?
I ask because in the scene I'm rendering, the building and detailed areas are ~1000 units apart on the x-axis. If I place a sprite somewhere on the detail map I need it to be ~35x35 pixels and when I do this it works fine for the detail view but building view is overtaken. I played with the numbers and it seems that if I scale the sprite by 4, it starts to show up on my building view, even though there's a 1000 unit distance between the views and the sprite isn't visible with the perspective camera.
So. If my understanding is correct then I need to either use separate scenes; have a much bigger gap between views; use the same camera type for both views; or not use sprites.
There are basically two different ways you can use sprites, either with 2D screen coordinates or 3D scene coordinates. Perhaps scene coordinates are what you need? For examples of both, check out the example at:
http://stemkoski.github.io/Three.js/Sprites.html
and in particular, when you zoom in and zoom out in that demo, notice that the sprites in-scene will change size, while the others do not.
Hope this helps!