- This topic has 14 replies, 4 voices, and was last updated 4 years, 11 months ago by
.
-
Hi. Thanks for the vote of confidence Pottsie :) . Was “offline” all day today, but looks like Mikhail did a good job of covering the basics, but i thought I elaborate a bit since you mentioned me;
So to go all the way back, and probably going over some things you may already know, cube maps is like if you take 6 cameras at the same position each pointing along one of the axis of the positive and negative axis with each camera having a square 90 degrees horizontal and vertical field of view, so putting it in the middle of a cube would have each camera covering one side of the cube exactly, and thus covering everything around it in 6 images, usually either as separate images or lined up in a 3×2 image containing all 6 “angles” and projecting that back onto a cube with the normals pointing inwards would then produce a view from inside of the entire environment. This was used in older games to make the map or level seem bigger, especialy for outdoore scenes, hens often being called skyboxes in games. Using just a simple cube for this was a big “quality/performance” win when poligon count used to be a bigger resource eater.
Equirectangular on the other hand is like wrapping a flatt 2D world map onto a UV sphere. This will then use much more geometry than a simple 6 quad / 12 tri mesh that the cube is made up of, but as computers are more powerful these days, that is not so much of an issues.
Bothe of these methods, or at least very similar methods, used to be done on actual static meshes in the scenes or levels of a game, making them not only change once you rotate the view but also move with changing position. As the skymap was mostly used to mimic the sky, the scale of the skybox/cubemap would need to be huge to do a good job. As most of us have noticed we need to move quite a distance down on the ground to notice any change in a cloudes actual position, so now moste engines have there own implementation to only project either the cubemap or an equirectangular map as if the camera is always at the center, effectively making the “paralaxing” non existant. Doing this mapping as a first/back-pass and not really needing any mesh to support it also means it can be done more efficiently in most cases.
With the basics out of the way, both mappings have their advantages, and I will only mention two points here that I see might being of particular interest in our context here;
As most enviroment maps these days are equirectangular they already have a huge advantadge or being easy to just pop in where you need them, and they are also alot easyer to adjust right in blender without having to go to different software to adjust. Say you got a HDRi and you want the horizont to be higher or lower , you can add a maping node and adjust it to move the horizon higher or lower without much noticable distortion, also rotating it around its Z(for blender) axis in smaler increments is also easyer. On a cube map that is potentialy a lot harder to do without recreating the actual map from a different location or doing som fancy maths on it, atleast if it is not mapped to an actual mesh, but then you have the problem of the scale and “paralaxing” again to make it more “realisic”.
Cubemaps on the other hand has an advantidge of being a lot more straight forword in a different way. The fact that it is just a straight camera and no distortion I think makes it a better candidate for potential realtime reflections where you could basicaly live project the 6 cameras to the 6 sides of the cube map, and moving the camera “rig” around with an object would recalculate the cubemap on every frame. I think think there is such a camera setup in three js, but i have not done a lot or research on that yet, but my guess here is that this ofcource would be expensive to calculate, doing this with an equirectangular map would be quite a bit more expencive.
So that is a bit of information, and this is just of the top of my head, so there might be a thing or two not quite acurate, but I think it gets tha point across.
If anyone else botheres to read this, pleas feel free to correct me if I made some wrong assumptions or inacurate statements here.
OMG. If i knew this was gonna be this long when i started writing I would not have started writing
but I hope you find this atlest a little helpefull, lett me know if you need anything clearifyed.EDIT: And in regards to the lighting, this is technicly an issue of the image format and not the mapping itself, and it rely comes down to what three js / Verge3D supports of the different implementations of the different mappings avalable, and I have not done the research of what options are actualy avalable at this time. There might be some internal remapping from one map type to the other to i guess.
Elk – this is all great information, thank you!
Ok, I think I’m getting closer to understand these concepts.
My main hangup now is when to use an environment map vs. an equirectangular map that is projected onto a sphere, for instance. Let’s just say for the case of an archviz application.
In your Environment Map Size thread, you mentioned having a “pre rendered” equirectangular map, for performance reasons on mobile. So is an environment map not pre rendered? Or am I not understanding another principle?
Again, thank you for your insight. Always so helpful!
Check out my sketch book :) | www.instagram.com/b.potts.art/
Glad you found it helpful
What i meant by “pre rendered” is simply that i render my entire scene into equirectangular maps, so instead of having all my geometry for my ArchViz to walk around in I will have a “view” from a couple of pre selected sport to move between, like the 360 photos you would se on facebook or like a 360 video on youtube.Something like the “Home Hazard Infographics” app in the gallery, but I would just use a renders from my archViz scenes instead of an equirectangular photo;
If you look straight up or down in the app you will se some slight distorition at the “north” and “south pole” so to speak, this is often but not always an effect of an equirectangular mapping, so in similar case a cube map could give better results. Performance vice i think it is not that huge a differens. Equirectangular is mostly the default these days, so would just go with that in most cases.
Oh, and the reason I am considering using a mesh instead of the environment itself is that I was having trouble with chrome not working properly with hight resolution maps on mobile for the enviroment, but mapping it to a UV sphere made it possible with higher resolution textures.
- You must be logged in to reply to this topic.