A few questions about cameras for a begginer

[turgodi]

Hello. This is my first post on this forum, i read the rules and i hope i'm not breaking them because i don't have a demo.

I need a way to display a 2d galaxy map (it will be in 3d, but it will be a top view) for my game, i will use Babylon.js, however i need some help on some points.

My map have 3 modes which depends on the zoom on the map; mode 1 where you see the planets (which are meshes); mode 2 where you see the solar systems (planets are hidden), mode 3 where you see the galaxies (solar systems are hidden).

Here is a representation of mode 1 with the zoom bar on the right : 

The red bar is the current zoom level.

My questions are :

- How to make a top view camera with rotation blocked but keep the wheel for zooming in and out ?

- How to make that i can move the camera on x,y with my mouse ? (Since the rotation will be disabled the mouse is free)

I will use camera.radius to get the current zoom level and dynamicly update the planets / solar systems / galaxies display with AJAX as a function of x,y coordinates.

 

Thank you so much.

 

[max123]

http://www.babylonjs-playground.com/#22OERW#0

Move target instead of camera

[turgodi]

Thank you max, this is really helpful.

I will try to figure out myself how to move the target with the mouse with the drag and drop example and it should all be good.

http://www.babylonjs-playground.com/?18

[Wingnut]

Welcome to the forum, @turgodi!  Ol' Max doesn't give a whole lot of details, does he?    It's okay, we love him anyway.

The drag'n'drop demo NEEDS a ground, to get a ground coordinates for its drag.  But it can be set ground.visibility = 0, and it will still work fine.

If I may ask some questions, what do you plan to use as a background for the overhead map?  Perhaps a black plane?

Anyway, I made a little demo, and put a starfield on the ground plane.

http://playground.babylonjs.com/#2JXSKY#10 

I made the green box into a green plane, but then made it ALMOST completely invisible (but set .showBoundingBox = true so we could still see it).  I also locked-down the ArcCamera with alpha and beta limits in lines 8-11. 

It works... okay, I guess.  Quite jerky, quite sensitive.  Mousewheel still working fine.

Now, let's wander off to ANOTHER modified drag'n'drop demo... where @Richard C and I worked on a "virtual joystick" for controlling an underwater vehicle.

http://playground.babylonjs.com/#2JXSKY#2

Pretend the little green mesh... is the submarine. 

Want a tour?  I knew you did. 

Just like the other drag'n'drop demo, this one needs a "ground" behind the joystick, so the getGroundPosition() function at line 53... still works.  Lines 32-38 builds the joystick bat.  Line 39-40 puts a do-nothing actionManager on the joystick, just to make the pointer change shape on mouseover.  Line 42 moves the pivot point on the joytstick... low, so it acts like a joystick when dragged.

Down to the onPointerMove... line 104... we are gathering "diff" just like the standard drag demo, but in lines 106-107, we are applying diff to the joystick's rotation.  Line 109 - 113 prevents the joystick from rotating too many degrees.  Lines 115-116 use the joystick's new rotation values... to set 2 variables... xspeed and zspeed... which COULD be... movement of camera above your map, or movement of map beneath your camera, right?    You betcha.

This demo has a "rampdown".  The little green submarine comes to a stop gently...  tapers-off.  If your map scrolling came to a stop gently, no problem, right?  Line 124 sets the ramp-down rate.  Line 125 starts the dreaded "render loop"... things to be done EACH FRAME.  Lines 127-128... pretty simple to see.  If there is an xspeed or zspeed, add/subtract it from submarine.position.  In your case... add/subtract it from map.position or camera/target position, right?

Now let's look at pointerUP at line 82.  We don't do too much here, except center the joystick rotation, and set stickInUse = false;.  Now let's look at lines 130-134 in the render loop.  If NOT stickInUse, start ramping down the current x and z speeds... until they reach 0.  Same with your map or camera (or cam target).  Taper off the movement to zero.

So, you can see that onPointerMove is very "hackable"... and you could "merge" the two playgrounds (#2 and #10) that I have shown you... and get a smoother map-scroll or camera scroll.  In a way, xspeed and zspeed are throttle settings for your map or camera "scrolling motor".    Lines 127 and 128 are constantly applying those throttle settings to the motor... but if xspeed and zspeed are value 0, there is no movement.  So your "scrolling motor" (cam position or map position) is always being "serviced" by the render loop... but sometimes there is no throttle setting, so... it stops... and waits for user to add "juice". 

There is one other method that might work for you.  http://playground.babylonjs.com/#TTLMJ#1

Here, there are invisible planes along the edges of the screen... parented to the camera.  I have kept the .showBoundingBox=true on the planes... just so they can be seen, for dev.  They use actionManager.onPointerOver/Out triggers on the 4 planes... to cause scrolling. 

This PG demo is setup for full screen, and some have said that positioning these invisible mouseover planes... can be difficult... when allowing canvas resizability.  But YOU, my friend, could use these invisible scroller-plates just above your map (slightly higher Y position), and make them narrow (make them be the map's border?). 

Not a bad way to scroll-around on your overhead map, eh?  And no need for drag'n'drop crap or a ground. No need to click, either.

Perhaps parent them to your map plane, and not to the camera  (BUT, there might be an issue where map scrolling causes map borders to move out-of mouseover condition, though.  The borders slide-out from under the pointer.) 

You might need to figure out a way to keep the borders to the map in one place, but scroll the view inside the borders... possibly using something called a renderTargetTexture.  A renderTargetTexture is like a view from a second camera... that can be used as a texture on a plane.  Here is a demo with 4 cameras feeding 4 renderTargetTextures... onto 4 planes that have been parented to the camera.

http://playground.babylonjs.com/#1WROZH#6

RenderTargetTextures are very useful when the overhead map is to be "windowed" into the corner of another camera view.  BJS also allows multiple "viewports" and assigning cameras to different viewports.  Here is a 5-viewport demo:

http://playground.babylonjs.com/#13TVWJ#2

It's 5 viewports because the blue divider lines are actually viewports, too.  Their cameras are shooting at a blue plane far away from the main scene... and their viewports are defined narrow.  Lines 26-55 position the viewports, and take notice that viewport positioning is done from the lower left corner of the screen.  Lower left is position 0,0, and upper right is position 1,1.  The 3 main cameras are "ganged-together" in this demo (they all move WITH each other), but that can be adjusted/stopped.

I hope this gives you some ideas.  Party on, keep in touch, we're here to help.  Again, welcome to the forum.  Good to have you with us.

See @max123?  THIS is how you give forum users... information overload tumors.  TMI cancer.  hehe.

[max123]

hehehe @Wingnut, if only you could channel your unabiding energy into improving bjs official documentation! 'cause if there's one area where Babylon lacks, it's documentation. Joking aside, you're a hell of an asset to the community - I've learned a shittone from your posts!

[Wingnut]

Thanks, Max... very kind of ya.  There's issues with letting Wingnut "go crazy" in the official docs.  Mainly, Wingnut gets talkie... and he over-explains.  This is because I have seen many mis-understandings in the forum... caused by language barriers.  Truth is, in the official docs, less is more.  It has to be real clean... just the facts, no Wingnut faerie tale metaphors or storytelling.  This is so... the docs don't scare/overwhelm non-native-English folk.

AND... Wingnut sometimes doesn't know what he's talking about and says wrong things... cuz he likes to speculate about how things work, instead of doing the actual research to find out.  Saying wrong things in official docs.... that's something I really really want to avoid.  So, I'm scared of the official docs, to a degree.  I'm really not qualified... yet.  Someday, perhaps.  But BJS is growing faster than I am absorbing, so it is outrunning me... and I spend many hours per day working with it.  I don't think I have the right qualifications and aptitude... to be doing much "official" stuff.

BUT, here in forum, which is nicely searchable and very well indexed by web search engines... I can talk some crap.  How many tutorials-in-a-post have I written in the forum?  Probably 1000.    Here, it is more OKAY for me to be completely full of crap... in my posts.  And it's okay to over-explain and reword things repeatedly... for the non-English folk. 

And, I can customize each tutorial... for a real-life user issue... a problem "live" from the field.  I can "work" the customer service ticket like a sponge... actually showing people how I would "think it out".  Then I make a "campfire project" out of the issue, and invite everyone on the forum... to "work the issue" with me (and correct me when I've speculated something far from fact).  We build a campfire party, and we get lots of perspectives on the issue, and lots of ideas... and we also learn about problem solving... from each other.  We learn about issue-solving process... sharing techniques to arrive at solutions and work-arounds.

So, here in the forum... we can get sloppier and dreamier... not worry so much about stating facts.  Instead, we can get wild and free.  We can still write tutorials-in-a-post and these forum-torials can be found easily with forum search.  Plus, these "get togethers" create "community"... and I'm a Christian-ish-commie (a collectivist? Marxist?  *shrug*)... so that works-out rather nicely.  As Red Green says... "We're all in this together".  I agree.  It's one big PARRRRTY!!  (Wingy rolls out a 9-foot bhong on a hand-truck dolly). 

But seriously, yeah, I look at the official docs... especially the beginner tutorials which I once custodianed.  They are old and stale... a bit.  Esp cameras tutorial.  But environment could be big-time fleshed, too.  Advanced texturing too.  Sigh.  But, when to flesh, when to divide into separate tuts.  When to talk more?  When to be brief?  Who made WIngnut the boss of how beginner tuts should be worded/written?  What makes him think he is anywhat qualified?  I'm having a nervous breakdown just THINKING about it. 

Here Max... take the baton and run with it.  Turgodi... back him up.  If you see him face-plant on the gravel... hose him down, and call the paramedics. 

[max123]

8 minutes ago, Wingnut said:

Plus, these "get togethers" create "community"... and I'm a Christian-ish-commie (a collectivist? Marxist?  *shrug*)... so that works-out rather nicely. 

When I replied to your post, I had a vague feeling your answer would be in the vein of "communal" vs "corporate", I shit you not!! Shame the National Lottery is closed for tonight...

Talking about the docs - I meant the "classes" part, not the tutorials; the latter are (mostly) beautiful. If you look at Java or AS3 docs, you'll see what I mean. The kind of documentation you can actually learn from, with examples (!). I know, I know... The dudes do it in their free time. And they command my utmost respect for that!

[turgodi]

Hello wingnut. Thank you so much for your post.

I looked everything and i guess i'll stick with moving the camera and the drag and drop deplacement ;

http://playground.babylonjs.com/#2JXSKY#19

Here you can see an estimation of the size i need...

A red sphere is one planet

The yellow square is one solar system, that's 25 planet

The green square is one galaxy, that's 100 solar system

The blue square is one universe, that's 100 galaxies

So it would be 25 * 100 * 100 = 250000 planets

let's say each player can have up to 15 planets, that would be enough for 16500 players with no planets left available.

I will load the meshes in real time with AJAX depending on the camera x,z and y axis. The y will tell me if i have to display a planet (low y), a solar system (average y) or a galaxy (really high y).

Do you think most computers will handle this ? There wont be more than 100+- meshes on the screen since it will scale to the 3 different modes, but the 100 meshes will all have a texture.

 

For the ground, i have no idea really. What would cost the less resources and look best ? The texture you gave me is nice, but it gets blurry when i'm close the planets, and gets too laggy if i turn up the resolution (2048/4096).

[Wingnut]

I like the gaseous nebula, personally.  None of the planets can see very far, and neither can any of the space craft.  Camera.maxZ set fairly low.  If a planet owner is really good, he can make contact with another planet... if he aims his radio dish correctly.  Other than random radio contact, none of them know how big the universe is.  They can't see each other, they can't travel to one another (easily), etc.  In thinking this way, how much area does any single user need to see... within their camera frustum? 

Sure, they can set-up their Sears "Junior Astrologist" telescope on the roof of the garage... but still, that only doubles the maxZ of their view.  Late night amateur radio enthusiasts might hear momentary bursts of alien chatter... but only with big antenna arrays and good luck.  They only get to see their closest neighboring galaxies... as tiny points of light in the sky.    You... on the other hand... get great performance because you are a camera frustum-meister.    (or at least a wizard of LOD - level of detail, a feature of BabylonJS).

Commies!  hehe.  The term carries such a distasteful wheelbarrow-o-baggage, eh?  But my commie ways come from 9 yrs in the US Air Farce... where we were all on the same team and took care of one another, because we knew that to hurt ONE member of team, hurt ALL of team.  *shrug*  Enough of that crap, though... let's get some interstellar battle going with turgodi's worlds.  SPECIES WAR!    My bets are on the Trumpelstiltskins... they can weave gold into straw.  err.  hmm. 

 

[turgodi]

I have a hard time understanding some things but i guess i got it aha. I'm french, english is not my native language.

The players will only be able to see the planets they discovered before, and the planets discovered by the members of his alliance.

However the player will still be able to zoom out a lot, but he won't see anything other than what he discovered anyway.

It will take month, maybe years depending on the number of players to get a complete map of the universe.

[Wingnut]

Well, you know how it goes.  The more mesh you need to render in-view, the worse the performance.  So... if you can do some good pre-planning, you might be able to avoid those bog-downs.  Others have traveled this trail.  A playground search or forum search for 'planets' or 'galaxy' might bring some interesting info.

It is difficult to answer the performance questions.  How much detail on each planet?  How many textures?  HeightMaps?  Shadows?  Post-processes (effects)?

Keep it modular, you know.  Make planet generator.  It's called by solar system generator.  It's called by galaxy generator.  etc.  That way you can easily scale the size of the game, later.  If things get too slow, simply call the generators less.    Down-scale.  Just a turn of a knob.  That's what I would do.  So, it is likely wise to avoid that advice.  

[turgodi]

I haven't made the planet models yet, it will probably be in lower resolution on the galaxy map, low poly ones...

i like this kind : 

I will try with textures, else i will just set a uniform color on Babylon

I need to look further in heightmap etc, i just discovered babylon js a few days ago and this is my first javascript framework, i'm a begginer.

I tried with a pretty cool code from someone to generate planet meshes, runs fine with 100 meshes

http://playground.babylonjs.com/#2JXSKY#20