elk

I will do some more reading on the AA methods, but I get the basic differences now.

Thanks for the quick and good response as always.

EDIT: Whoops, sry, wrong threed :S

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;

Made with Verge3D

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.

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.

That was quick :) works for the animationCount setup, the simpler setup still does not work as I was initialy thinking, but putting enable rendering also in “while moving” now makes it behave fine. I think I have been thinking about the list iteration wrong, but testing this out, and with the bug fixed it makes more sense.

Thanks Yuri

So going on my prevoius assumption that the “loop” is run for every object in the list I still get the same problem as before, the last object “override” the rest of them somehow. I tried with the setup in attached screenshot, there I will enable the renderer once 1 or more objects ar moving and only disabeling when the the number of moving/animating objects reach 0 again. (not visible in my screenshot, but i set the animationCount variable to 0 at the top of the current puzzles tab)

I could sett up puzzles for testing my assumptions here, but I think my assumptions here are wrong, or something about the inner workings of the when moved puzzle combined with lists are not quite right.

If I could get a quick explanation of how the logic flows inside the when moved puzzles using lists that would be great!?

EDIT: sorry about the rant but I’m just editing as I make assumptions, is it like a switch statement of sorts ?, so once one object is found to trigger a condition it will use that, in effect for my setup just using the first object it evaluates ? That sort of would be consistent with my findings so far.

Just tried the SSAA, and some apps just won’t start or get darker. So I tried setting up a new app and and just going into puzzles to add the SSAA, and the default scene does not show the gray background, and the cube looks a bit darker/more contrasty.

The SSAA at x16 looks great tho Tried rexporting but saw no change. Tested in Chrome and FF on windows 7.

Anyone else getting the same thing?

EDIT: so after a bit more messing around it seems that you can’t set the supersampeling by itself, like if you want it to be on from the start, putting it in a block of some sort seems to fix the darkening and the background going black (like a after 0 second(s) block for instance), I am guessing that there is some buffer that is not ready if you set it directly. Hovever, I am still getting a frezz on another scene, but that might be some other conflict, will try to resolve it tomorrow.