koobas.hobune.stream
Can we create our "own" terrain "engine" on Unity ?
Hi all,
The terrain component in Unity is inappropriate for my own project (and I find that the number of Draw Calls is very huge...). I was wondering if we can develop our own LOD (Geoclimapping or Quad tree) + if the only class which allow us to build geometry (Mesh interface) are sufficient ? I ask these questions because we have a very little control on the rendering pipeline and we can just manipulate buffers (vertices, indices).
Thanks in advance.
I believe there's some C++, but mostly it's C#, from what I read. Certainly there's nothing about it that I can see which would require it to be C++. Also there are various third-party terrain systems available.
Hi @kev
if you mean the actual mesh changing depending on the camera distance, yes that is trivial to do with ordinary javascript. No prob whatsoever.
(I'm not fancy enough to use C# .. but I believe all the monoscript scripting languages ultimately run in Unity3D at exactly the same speed.)
you're aware that Unity has a "level of detail" (mesh) system fully built-in and awaiting your fingertips??
Here it is ...
http://docs.unity3d.com/Documentation/$$anonymous$$anual/LevelOfDetail.html
if you mean the texture changing with the distance to the camera, i just use the ordinary old mip maps built-in to Unity3D. (ie, "the textures I come across, already have both in there!")
I've never found any problem whatsoever, at all, making a quad tree, spatial hashing or the like, or any sort of everyday "comp sci 201" algorithm in javascript. (I've never done geoclipmapping.) It seems really fast to me. There's talk that the whole unity chain starting with javascript, is only about 50% slower than writing native ObjectiveC in XCode for your iPad, so perhaps that's some sort of specific answer for you. You know how someone's always co$$anonymous$$g up with a cheesey new algorithm to make idiotic looking fractal-ish terrain for 3D games? There's talk on the forums from time to time of people implementing those with no trouble in c# inside Unity, so I think it's a non-issue. Just as Eric says I can't see anything at all where you'd have "language concerns" in the topic you're discussing here. (Indeed you should look around for already existing realtime-lumpy-shapes stuff in Unity! Someone should throw one in the asset store really.)
"I ask these questions because we have a very little control on the rendering pipeline..." I'm completely with you on wanting to "get lower in to" the mesh pipeline (perhaps you could add an essay answer for my current question here ! http://answers.unity3d.com/questions/297697/explain-the-vertices-pipeline.html ) but it's not gonna happen in a gameEngine, eh? It is what it is, it's meant to be a "game engine" not, oh, a "low level mesh/ OpenGL engine system thingy". (I wish there was such a thing!)
Why not spend 10 $$anonymous$$utes scribbling out some code that, in a word, changes the mesh in the way you're thinking of - it will instantly answer many performance questions for you!
{How to annoy a group of programmers, make a paragraph-numbering system that breaks! Arrrg! :) )
The Unity built-in terrain is mostly written with C# scripts. So, yes.
Yes you can but you'll need to write extentions for it in C# and C++.
The Manual goes over the topic Here: http://docs.unity3d.com/Documentation/Components/gui-ExtendingEditor.html
Hmm, @super, what are you thinking of when you figure it would have to be done in an Extension? Pls explain as I am stupid. Cheers ..
Well, one example scince we're talking about terrains is the custom built Terrain Toolkit made by the Sixtimesnothing dev $$anonymous$$m. $$anonymous$$ade in C# it is a fully operable custom terrain engine based on math sequences. You can make any extension to unity. The link in my answer goes over it pretty well. Look at the first picture and the caption, but imagine it as the Terrain Tollkit that you made.
Super, that's a very admirable product and everyone should buy it NOW.
But note: unless I'm mistaken (Eric?) there is no PERFOR$$anonymous$$ANCE aspect whatsoever to using an extension.
If you can write the code it will work basically identically in everyday code or an extension. There's no performance difference. It's essentially a matter of "convenience" to "put it in an extension". I'm pretty sure that's the case dude! Rock on!
You wouldn't need C++. I'm not sure what you mean exactly by "extension". If you mean DLL, Fattie is correct, the code in a DLL is the same as code in "normal" scripts, it's just packaged differently, and it's not necessary, just a convenience.
