OldUnreal (Engine)

--- Download Links ---
The latest version of Twirl! can be found on the projects page at the UDHQ site: Twirl Project Page or through this Direct Link

---

[/color]Update 8/25/11
I've been seeking to address a couple known issues with Twirl!.

1.) Twirl! takes up 100% cpu usage when the mouse is pressed. This is because of an unintended recursive call happening in Windows that is triggered by my code.
>    This issue has been addressed. I now have a way of capping the framerate to a flat 60. This frees up the CPU to a large extent (decreased to ~25-30%).

2.) The mouse sometimes escapes the window. This bug can be reproduced by holding down both mouse buttons, releasing only one of said buttons, and moving the mouse rapidly. The mouse will escape the window and the program loses focus.
>    This issue seems to have been addressed. I think that it had to do with some errors in OpenGLUT (the windowing API) that I've recently fixed. After applying the OpenGLUT fixes it seems that the escaping mouse problem is no longer present in Twirl!.

No release date is set for another revision of Twirl!, but I'm definitely still at work on it.

---

Update 8/23/11
Twirl v1.0 is out! It can be found on the projects page at the UDHQ site: Twirl Project Page

... and if you're like me and hate going through sites: Direct Link

I added a bunch of stuff to Twirl before finally deciding it was release worthy. Upon exporting the terrain, a heightmap is also exported which may prove useful for those who wish to hand tailor a texture to display on the mesh. Users can now also cycle between different draw modes to get a better feel for the terrain. I am aware that lighting would also help give depth to the terrain, but at the moment it doesn't seem critical enough to further delay the v1.0 release.

As always, any feedback is appreciated. Have fun!

---

Update 8/21/11
Got the exporter working and beta tested a massive terrain in Unreal! (64k+ polygons) I'm happy to say that the performance with static meshes was more than I would have hoped for -- my FPS dropped from 62 -> 47 when viewing all 64k polygons at once, and when actually on the ground and walking around I did not notice any performance drop at all!

a render of the terrain in GLC_Player (an OSS obj viewer)


screen 1 -- corner view of the terrain


screen 2 -- casey wants the source to galaxy?!?


screen 3 -- random bot on the terrain



I think that Twirl is very close to a v1.0 release. For reference, the above screenshots were taken by simply throwing Unreal's default texture on the terrain and lighting it with a sunlight actor.

---

Update 8/20/11
Generated terrains now have correct normals. This is important for correct lighting (though I'm not sure if Unreal uses vertex normals for lighting as opposed to goraud shading with triangle normals). The next step is to get the file exporter functional, after which a formal release can finally be made.

normals calculated per vertex

---

Update 8/19/11
Managed to mess around with the heightmap generation algorithm and (after reading the fine print, for once) have confirmed that the "spiky" behavior of the terrain is indeed a property of the Diamond-Square algorithm itself. As such, this is deemed "expected behavior" of this algorithm and I will not seek to correct it. This is not to imply by any means that this will be the only algorithm implemented!

I also got the UV mapping applied and have provided screenshots of a couple textured terrains. Note: yes, I know that one of them may be considered offensive. I will understand if the image is removed, but I thought it was hilarious so I left the texture on. :p

a texture mapped onto the terrain displayed previously (the 180x180 one)


another texture mapped onto the same terrain

---

Update 8/15/11
Fixed a few bugs with the heightmap generator. It was overflowing on certain randomized vertices, causing vortexes or spikes to appear randomly in the terrain. This has since been fixed, but I believe there to be another possible bug regarding smoothing of the terrain. I believe that I'm reducing the random number range too quickly and will investigate into a smoother randomization function.

large terrain (180x180 -the max- resolution)


As you can see, the terrain is still riddled with smaller spikes. This definitely has something to do with the randomization threshold, which I'll be soon looking into.

---

Update 8/13/11

I've been working a lot on the rendering aspects of the program, but the terrain generation method is implemented in full. I finally have a render of a simple 4x4 grid of a randomized terrain:

random bs terrain


cool topography that got generated by a bug

---

I have recently begun work on a new standalone application that will enable users to automatically generate random terrains for Unreal.

I have recently had some success in implementing a simple algorithm and should be able to create full T3Ds (importable to Unreal Ed) in the next few days. Ideally, I will support a range of algorithms and let the user decide which they wish to try, but there is always the possibility of having extra features. As such, I would like to know if there are any specific features for the generator that mappers in the Unreal community would benefit from. One immediate consideration is the output of the actual heightmap in BMP format so the mapper could perhaps use the heightmap information as a "minimap" of sorts.

I'll update this thread with the progress on the generator (hopefully with some awesome images as it comes along.

Can you import T3Ds as static meshes? Static mesh terrain has a benefit of using soft lighting and better tolerance of high polygon count.

Can you import T3Ds as static meshes? Static mesh terrain has a benefit of using soft lighting and better tolerance of high polygon count.

Not very necessary is you can just import the brush and convert it to static-mesh in UnrealEd.

Yes, but it would still be nice. And maybe even more optimised or something...

Can you import T3Ds as static meshes? Static mesh terrain has a benefit of using soft lighting and better tolerance of high polygon count.

Great point. obj files eliminate a lot of redundancy found in T3D files; I'll add an option to export as obj.

Main post updated w/ sample render of a basic terrain.

Right now it sounds like TerraEdit with random generation. Make sure you generate clean terrains and not the horrible stuff shat by TerraEdit (as explained by bot_40)

Right now it sounds like TerraEdit with random generation. Make sure you generate clean terrains and not the horrible stuff shat by TerraEdit (as explained by bot_40)

Thanks for the reference! I too cringed at seeing how similar it looked to something from TerraEdit.

After reading through bot_40's tutorial, I think that a couple techniques would really help. First, I will tessellate the triangles differently (like UT200x's TerrainInfo terrains) and second I think that the terrain needs some dithering. I can already think of a couple methods: introducing some wavyness to the columns or rows of vertices (by modulating with a sin/cos) or straight out using randomization. I think that better tessellation and dithering will make the terrain more similar to that explained by bot_40.

One thing also : TerraEdit produces terrains that are specifically supposed to be added : they are either a sheet too add as a terrain or a big block with the upper face made to look like a terrain (I don't remember exactly at the moment); it causes horrible bsp cuts and may possibilities for HOMs. It would be much better if you generated terrains in the way of the TerrainBrushBuilder : as a brush with the inside of its inferior face pushed outward. See what I mean ?



For mappers, it makes a huge difference. Cleaner BSP, less obfuscated viewports, easier to manipulate, no problem with brush orders...

Yeah I understand. I've been a mapper almost twice as long as a coder so I know what you mean about the subtractive geometry for terrains.

However... I was thinking of restricting the output to the obj format for use with 227's static mesh actor. I've heard from a couple mappers in particular that highly tessellated terrain can cause BSP issues and I wanted to avoid that altogether. In any case, adding a some polys around the sides and making a closed form subtractive brush isn't hard at all if it really is in popular demand to output T3D.

(I've also updated the main post with a new image. It uses the same old tessellation, but I fixed a few bugs with the heightmap generator and the result is a nicer looking terrain, at high resolutions, anyway)

Oh yeah, that looks awfully nice, but also painfully slow to run on Unreal.

Main post updated with UV mapping implementation screenshots.

Eh, now THIS is a great feature. My main problem with DmRiot's BSP terrains (then converted to static-meshes) was texture work (in the final version, it's still rushed). That sounds awesome.

Main post updated -- per vertex normals now calculated.

Main post updated with in-game screenshots of a hi-res terrain in Unreal.

If that's the default texture, then why isn't it bubbly?.. Would be nice to see an actual GenEarth texture on it.

Untextured maps > textured maps. The book of Enderz has a well described passage on this.

Do you allow to download it by uploading it somewhere on net??

Obviously its the moon.... Are you people BLIND?? :-/

Do you allow to download it by uploading it somewhere on net??

It is still in development

Do you allow to download it by uploading it somewhere on net??

It is still in development

Pitty. Thanks

Obviously its the moon.... Are you people BLIND??  :-/

No, that's the moon:
http://images3.wikia.nocookie.net/__cb2 ... andard.jpg

...well, given the lack of MacroTextures there, I guess your version of the moon looks better. :-/

Earth is a moon(technically satellite) of the sun. But that's still crap.

Main post updated with download link!

Main post updated with information about known bugs and future fixes.