Branch/terrain

[rchadwic]

Integrate the terrain engine from the Sandbox fork.

Currently, several properties that should probably be editable are hard coded. See the included example under public/ADL/terrain/ for parameter reference.

bUrl,gUrl,rUrl,baseUrl - url's to tileable images that splat into the mixmap channels
mixUrl the mixmap to use to place the splat texture. Tiles exactly once over terrain
diffuseUrl a url of an image that is shows in the far distance. Tiles exactly once over terrain
worldLength,worldWidth - how many meters does the heightmap cover?
url - the heightmap. White is high, black is low.
heightScale white is 100 * heightScale meters high.
cubic - use bicubic instead of bilinear filter
addNoise add some simplex noise to the heightmap
Extents the total range of the system. When using the heightmap algorithm, best to set to same as worldWidth

[BrettASwift]

@rchadwic Would it make sense for us to move the terrain code into its own driver instead of putting it in the threejs driver?

[rchadwic]

Well, I'm not sure that would make sense... Unless we create some method for the drivers to share access to the threejs lib?

[eric79]

We could add three.js as a dependency of the terrain driver in the define line, and that should give us access. I do think I like the more modular approach if it's not too much work.

[rchadwic]

Humm. How would the terrain driver access the root scene node? Is there some shared state between the drivers where the ThreeJS objects could live, so multiple drivers could manipulate them? I agree that the 'load script' bit in there is a bit hacky. We could reform the terrain engine as a Require module pretty easily and make it a dependency of the ThreeJS model driver , but then you are loading a huge chunk of JS even for scenes that don't require it. There must be some way to load large bits of ThreeJS model driver functionality only when a node is created which
needs it.

[eric79]

Hmm ... that's a good point. I was thinking that the terrain driver would have the parent node id, but that's not good enough, if it can't get to the parent's threeObject inside addThreeChild. The terrain driver would technically have access to all the threeObjects, but without the nice data structures linking them to node ids that are in the threejs driver.

So, this might be a moot point, but I was actually thinking of doing the dependencies the other way. The terrain driver could depend on threejs and that way, only apps that needed the terrain would have to load that driver, but it would still have access to all the THREE functionality that you use inside.

And yes, loadscript might be a bit hacky, but I also sort of like it. I like the idea of loading only what is necessary. We're already loading a ton that maybe we shouldn't.

@BrettASwift, I don't know if you had looked into how to bring modularity to the drivers and/or if you have ideas that we're not thinking about. If so, we'd love to hear them.

[BrettASwift]

@rchadwic I've rebased this on the current development. Is it alright with you that I push the rebased branch up or do you have local changes or anything that would make that a problem?

I've also added a branch with your code as a driver here: https://github.com/virtual-world-framework/vwf/tree/branch/terrain-driver

I need to do more work to it, but it does what it needs to do for now.

[BrettASwift]

@rchadwic What is vwf/model/threejs/transformable.js? Is that a file of yours that is missing in this branch?

[rchadwic]

Ah. Yes - that's where I implement all the logic for get/set transform. Not necessary for this, unless you want to be able to move the root node of terrain. I'm not entirely sure how that would interact with the current Three.js driver.

[BrettASwift]

Pushing up the rebase.

[BrettASwift]

@rchadwic There are things in here that we really need to be able to configure from the application side, such as the atmosphere/fog. Do you think it would be possible to use the ThreeJS scene fog instead of the built-in atmo/fog? Or, do you think we could make the atmosphere settings visible in the VWF model (attached to the scene or terrain object) without spending too much time on it? If the latter, then I have just one concern and that is that the distant terrain doesn't blend to the atmo/fog color, so we are seeing a bright (almost white, especially with an HDR shader applied) horizon. I'd like to be able to control that better.

@eric79 Any thoughts?

[eric79]

@BrettASwift, my only thought is that I would love to integrate @rchadwic's atmospherics as well (sun, time of day lighting, etc). I imagine that it ties in with the fog, etc in some fashion, so we just want to take that into account.

@rchadwic, is that already in this code or is that separate functionality? I would love to see it in here. (and then, we'll probably want to make the sun smaller in the Mars Game ... but that's a topic for later) 😄

[rchadwic]

So - we patched the THREE.js library to have a whole slew of new fog parameters. Our atmosphere system includes modifications to the core Three.js renderer where it sets the uniforms, new properties on the Three.fog object, changes to the Shaderlib fog fragments, and then a custom shader for the sky. Merging that could get pretty ugly. Let me do a quick diff on my three.js file and yours.

[BrettASwift]

Either way, it would be good to have some consistency there. If we could get all of the assets in our scene to be affected by your atmosphere stuff, then I would be happy with that too.

[rchadwic]

It might be easier to revert the atmosphere part of the terrain shader to the original three.js quadratic fog. Would that be acceptable?

[BrettASwift]

I think so. @eric79 What do you think? At least for the short-term?

[eric79]

@BrettASwift, I guess I would want to see what it would look like. I know that the current fog looks more earthy than mars-y, but other than that, it sure looks nice.

I would say give it a shot (once you feel better), and if you like the result, we can go with that for now.

@rchadwic, thanks!

[rchadwic]

So, I'm in the process of aligning the fog in the frag shader for the terrain tiles with the default three.js fog system. You want this directly on this branch?

[BrettASwift]

That would be fine. Thanks, Rob!

[rchadwic]

Hey, actually - am I missing something? Where are the fog settings for the scene object defined?

[rchadwic]

Ok- done. The fragment shader for the terrain tiles now uses the default threejs fog rendering. Ah shoot - I checked this into branch/terrain-driver. Is that where we're working now?

[eric79]

@rchadwic I think that will be fine. I believe that @BrettASwift was doing a spike to see if he could achieve your modular driver goodness using the existing driver infrastructure. I think he was coming close to something that he liked at the end of the day (before he took ill with a stomach virus). I believe that his plan was to issue a pull request back to this branch and ask for your opinion on it. If we all like it, then it will get merged into this branch anyway. 😄

Thanks for your help!

[rchadwic]

@eric79 Great. That branch seems to work fine to me. I just branched off of it and commited a merged three.js lib that implements our atmospheric rendering for all objects. The trick is to set Scene.fog to Three.FogExp2. This object now has a bunch of new properties which should be aligned with a bunch of new uniforms in the materials. FogExp2 will only render the fog if there is at least one directional light, since it uses the sun direction as part of the calculations. In Sandbox, we make all those settings properties of the scene.

[eric79]

@rchadwic, sweet! Thanks!

[BrettASwift]

@rchadwic When I add fog to the scene, the terrain shader fails to initialize and everything breaks. I've been trying to figure it out, but I haven't had any luck. Any ideas?

[BrettASwift]

It seems it breaks in Chrome, but works in Firefox.

[BrettASwift]

@rchadwic Is there a trick to get shadows to work on the terrain? I can't seem to get them to show up.

Also, it looks like Firefox and Chrome place the terrain at different heights.

[rchadwic]

@BrettASwift No, there is no current support in the terrain pixel shader for shadows. I'd love to see that.

How are you adding the fog? I tested in chrome by hard coding the scene.fog, and this seemed to work as expected.

I have no earthly idea why firefox and chrome would be different. let me take a look

[BrettASwift]

I was hard coding the fog as well. Chrome Version 34.0.1847.131 m

[rchadwic]

@BrettASwift So, in the terrain-driver branch, using Chrome 34.0.1847.131 and Firefox 29 I have identical renders in the /adl/terrain scene. What versions are you running?

[rchadwic]

@BrettASwift can you test something? On line 2095 of the THREEjs driver, can you add:

 node.threeScene = new THREE.Scene();
 node.threeScene.fog = new THREE.FogExp2();
  node.threeScene.fog.density = .002;

This works for me in the version listed above.

[BrettASwift]

@rchadwic I was on FF 28, but I updated and it did the same thing. I thought that maybe it was because I adjusted the heightscale, but putting that back to 1 didn't fix it.

The fog, implemented as you wrote above, is still breaking in Chrome for me.

[rchadwic]

@BrettASwift - Shoot. Not cool if I cannot recreate it. Possibly a shader incompatibility? Do you see anything useful in the console?

[BrettASwift]

@rchadwic Not really. I looked up the issue earlier and all of the similar problems had something to do with ANGLE and a precision mismatch (highp vs mediump), but when I was debugging, the fragment and vertex shaders seemed to match. Odd that it works fine in FF, but not in Chrome.

[rchadwic]

@BrettASwift hummmm. Any additional tips on how I can reproduce?

[BrettASwift]

@rchadwic I have no clue. I'm just running directly off of the terrain driver branch. I seem to be running the same browser versions as you are. It fails on both ruby and node in Chrome. Unless you have changes that aren't pushed in, I don't know where the difference could be.

I've asked @eric79 to see if he can reproduce the issue. Maybe that will provide some insight.

[rchadwic]

@BrettASwift Here's a thought - I know I've seen at least one Linux box complain about specific lines in a shader that were fine on Windows. The issue specifically was vec3 blah = vec3(0.0); and the solution was vec3 blah = vec3(0.0,0.0,0.0);. I don't think that particular issue is it, but it does seem at least possible that underlying differences in the host OS graphics system can cause bugs up at the WebGL level. What OS are you running again?

[BrettASwift]

@rchadwic I'm running Windows 7.

[eric79]

Interesting ... it actually doesn't work for me in Chrome, either. I get an error message:

could not initialise shader

Could it be related to this?

[rchadwic]

@eric79 Yeah - very much. That shader does require the standard derivatives. Can you check that your GPU supports that?

[BrettASwift]

It seems as if THREE.MeshPhongMaterial uses that as well and that is the only material type we use in VWF, so I'm assuming that isn't the issue. Plus, it worked before this change and it works in Firefox. I can't find anything explicitly stating that it is or isn't supported, but my machine has an nVidia Quadro 4000.

[eric79]

@rchadwic, it looks like the mars-game team is favoring terrains with more authorial control so we can have more control over narrow flat parts for mazes, etc. So, with that said ... would it be crazy for me to try to pull out bits of the terrain branch into separate modules so we can still use them? I have my eyes on the texture blending, first.....

[rchadwic]

@eric79 Hey sorry - somehow I missed this. So - you can use the mix map to control which textures go where, but only down to whatever area is covered by a single pixel. The mix map should fix exactly with the height map. If you need something more specific than that, I think you'd be better off with 3D modeling the exact environment you want. The terrain system is really built for fairly large environments.

Can you give me an example of what you are looking for? Maybe I can poke and see if the terrain engine can be configured to get there.

[eric79]

@rchadwic, no worries! I appreciate your help. Maybe if you take a look at the current Mars Game app, it will help illustrate. See how the textures are way too low res up close? I was hoping to use your texture blending in the mipmaps to allow for much higher resolution textures up close ... but while still allowing our artists to craft the terrains by hand.

I believe that what I want is to tile the rgb textures over the whole terrain and blend them in the highest res mipmap. I guess one question is ... how do the mipmaps work in three.js. Will it sample from different mipmaps for one object if the object is horizontal to your line of sight (so part of it is very close and part of it is very far?)

[BrettASwift]

@rchadwic @eric79 At the end of our chat today, I realized that Firefox and Chrome are still rendering the terrain inconsistently. Could there be some compression or something happening on the heightmap in either browser, causing the inconsistency?