Hey everyone I am Paul and I wanted to ask some rather noobie questions to help get my feet on the ground pertaining to VR Development. So please do forgive my ignorance in some areas.
Rig/Setup - In reference to the demanding nature of stereoscopic vision and the 75hz-90hz requirement I have heard about what would be, in your opinion, a good desktop/laptop to develop on. (IE: i7 cpu with a GTX 980, 32g of DDR 3 RAM etc) Also where is VR most cost intensive, CPU, GPU, RAM, etc?
Your thoughts on asset creation for VR compared to a regular 3d game, anything special I should keep in mind that you have found? (IE: Normal maps look terrible in VR, or so I hear, so using Bump maps or Tessellation is a better route)
When developing for VR at the Indie stage it appears my only current dev kit is the DK2 (or Gear, but I would rather focus on the DK2 for higher fidelity). How hard/simple do you think it will be to integrate other VR products into a game designed with the DK2? (IE: I design a game in UE4 with the DK2 in mind, but also want it to work eventually on Morpheus or Valve’s Vive) I know this is very speculative at the moment, there is no hard answer, but I would like to know your thoughts.
Input - When designing for a PC oriented experience with say the DK2 should I use mouse/keyboard or controller, or make it for both so people can use whichever they want? (Obviously this question is different in reference to say the Morpheus where the PS4 controller will be utilized or Vive where the hand paddles and room lasers are used)
Any tips or tricks, or things you have learned the hard way to help out a fledgling VR Dev?
Thank you for reading this and I hope you found the questions at least somewhat knowledgeable.
When it comes to 3D models they always say that it is all about the quality of the texture as opposed to the number of polygons present on the actual model itself. This does not hold true in stereo due to the fact that you can see depth. Now I’m not saying you want to create some billion polygon face but you absolutely must respect all aspects of depth in relation to the model as well as it’s surroundings. Another thing to keep in mind is that your camera is now going to function as virtual eyes. Alot of graphics tricks work in traditional gaming because they are simulating what your eyes would do if you were there. They do not translate well into HMD stereo because you are now simulating your own personal eyes as opposed to looking at a monitor in the distance.
Also keep in mind is that framerate is king. Do not go out of your way to make something look good if it impacts performance. If you plan to go down the road of the DK2 you must respect the fact that you are going to be running high resolution games on a cutting edge engine… not everyone’s computers can handle it at a fluid (+)60fps.
With the way Epic has handled the DK2 I do not see things changing much on our end in terms of the new units. They all basically use different methods to function the same way. I’m confident that the basic functionality of the units will be well documented once they receive official support in UE4. This is of course a shot in the dark as much can change in little time.
Implementing both is not difficult at all but your best option would be controller with the look up and look down removed. You want people to be controlling that aspect with their head as it is much more immersive. Check this post I made in another thread for a more indepth view on basic input: Current VR Game Design Flaws! - XR Development - Epic Developer Community Forums
Figure out if you are going to create a project based off simulation or based off entertainment. If your end game goal is to create something that is basically the new wave of video game entertainment then remember that too much simulation can be a bad thing. No one wants to spend 5-10 seconds reloading a gun in an arcade shooter. Vice versa if you are attempting to create a simulation then nothing is more unimmersive then say “Press B to Open” as opposed to controlling your arms and making them open said object. You have to figure out what it is you want to do then figure out which side of those two spectrums you wish to lean more towards and then respect that choice until completion. If you start out as an “arcade” game then slowly evolve into a simulation then you are going to be doing ALOT of backtracking with your development.
You listed the specs yourself. VR is GPU intensive to say the least.
Up close (say, within 4 feet or so) is when normal maps start looking bad. Billboards are terrible: If you set to “look at player” then it appears unnatural. Either way, billboards lack depth, and they look bad. Very bad. You need to focus on LOD’s (both model and texture), tessellation, displacement mapping. My thought experiment on the matter is this:
Take a brick wall:
Previously, textures and normal maps where fine. But when you look close at them or from the side, it appears flat and bad. So… at a distance, you would use a quad with a material (texture, normal map)… as you get closer even closer, you want to use LOD’s to bring out the very large features (the bricks in the mortar), tessellate the quad and use a displacement map to make the “large features” pop out. The small features (such as the pores in the brick) don’t need to be displaced and is just taxing the system for no reason.
That’s up to the engine and how it can port the design to different devices. It’s speculation at this point, but engines like to be as hardware agnostic as possible so that developers can release to as many people as possible.
Gamepad or “Game specific controller”, ie: a HOTAS for a flight sim, for example. Keyboard/mouse? GTFO.
Games cost money to make. Alot of money. Why did I start doing this again? gdmit. Oh… something positive? Err… take your time, download a bunch of demos / experiences / games, learn from them on what works and what doesn’t. Read all of the documentation about best practices. Learn about reality. No, seriously… exaggerated movements like I always see in games make people sick (best practices), so make the movements as realistic as possible. Experiment, iterate, experiment, iterate. Make a small game, get feedback. Learn. Learn alot. And then, learn some more.
While designing VR is hard, the payoff is far greater than that of designing a normal game. I have a non-gamer friend of mine who, needless to say, isn’t much of a geek at all. I let him play a horror demo on the monitor, and he was… bored, to say the least. I let him do the same demo in VR… and he couldn’t stop talking about it the entire night; even to people we just met at the bar. That is the payoff.
Absolutely this. Appreciate and understand the real world around you because the people with little to no experience with VR will immediately feel sick or uncomfortable if your head is bobbing around while moving in tight spaces. Putting objects too close to the camera or even a ceiling being too low is enough to make some people want to take the headset off. Hell I’ve even seen people get scared of their own shadow.
Absolutely, VR is something outside of normal gaming. It evokes true emotions and doesn’t neccessarly require the greatest graphics to do so. In fact Minecraft like graphics still bring out emotions. It’s not the fidelity or graphics that does it, it’s the sense of presence involved.
Look up best VR practices like others have said, most of the stuff is intuitive, but there are some things to consider (like never ever taking control of the camera away from the viewer, even in menus or cinematics).
If you want the game to look good and run well on most computers, you will need to know how to optimize (e.g. LODs, culling, etc.). Biggest performance killer is dynamic lighting, you will want to use static lighting as much as possible. Any impact something has on the performance of the game in 2D will at least be twice as harsh in VR (since it has to be rendered twice for each eye). Break up the scene in clever ways to cut the players line of sight so you can avoid pop-in/pop-out and cull unseen objects. For example, in a cave system if you have large caverns separated by tunnels, make sure the tunnels curve/turn in a way that prevents the user from being able to look into both caverns from one position.
Avoid having the player looking up and down a lot.
Make the player’s collision a bit larger to account for players being able to lean into meshes since the head has no collision (and adding head collision would be quirky). Reduce the player’s normal walking speed. Also, head-bob is bad m’kay, so you will have to fiddle with the camera attachment to the static mesh (use VR template to save yourself some trouble). The head mesh needs to be separate from the body mesh so you don’t see parts of it in the camera, but it’s still there for the shadow and for others to see if multiplayer (again VR template).
From a UI standpoint, 3D menus and look-based controls (look at this button and a fill-up bar pops up, if player stares at button for 1.5 seconds, activate button) can add immersion to your project. For crosshair type of UI elements, you will need to be creative. For example, in 2D games, crosshairs are basically stickers that have been placed on the camera lens; but in 3D games, players’ eyes will actually focus differently on a target at various ranges, the 2D crosshair’s inability to move or scale to the object’s distance will frustrate the players like dirt being on a pair of glasses. So, you have to make a crosshair that can dynamically change based on the distance to an object, but the distance can’t be too great or you will lose sight of the crosshair (I just put a clamp to limit the distance my crosshair can be drawn away from the camera, see my answerhub post below for an example).
There is a lot of other small things you will notice as you go, but you should be fine with enough persistence :).
