Feature #488

FATE usability

Added by Mateos almost 6 years ago. Updated over 5 years ago.

Status:New% Done:

0%

Priority:Normal
Assignee:Jacker
Category:-
Target version:1.4.5
OS: Arch:

Description

Good evening,

FATE was an other software doing the same as EasyGen, released later, but never completed itself, and lacks key features: you can only make a terrain and export it with it.

But heh, the terrain editing is easier with it in fact, compared to EG using keyboard shortcuts and all, just the mouse is needed here, and you can choose if you want triangles or more complex brushes.

I think if you can port the usability of FATE to EG, it would definitely make FATE useless, and EG dat master reference, really.

You can find FATE here:
http://www.vis.uni-stuttgart.de/~rose/stuff/fate/index.html

Thank you

fate-shot.jpg (761 KB) keMoN, 21.01.2014 19:05

radiant-shot.jpg (1.47 MB) keMoN, 21.01.2014 19:06

280
281

History

#1 Updated by keMoN over 5 years ago

I agree with Mateos that terrain creation in FATE is far easier. This is primarily due to the fact that you can draw your terrain freely with the 3 dimensional arrow-set you’re provided with, instead of having predefined hills that you need to move around and modify in width/height.

On the attached fate-shot you can see what I mean with the "3 dimensional arrow-set". This should DEFINITELY be implemented in the new EasyGen!
Also I made a quick sample terrain in FATE so you can see the more advanced terrain manipulaton that is provided in it (x/y/z-axis instead of only z-axis)

Camera Movement
While I agree that terrain creation is simplier in FATE, I don’t agree with copying the camera movement/mouse keys.
The camera movement in Blender is far nicer to work with.

Here are my suggestions for camera movement:
press mousewheel - look around while remaining in one position
scroll mousewheel - zoom +/-
right mousebtn - move the camera position
left mousebtn - terrain manipulation using the arrow-set

x/yz-axis terrain manipulation
rough possibilities are shown in the attached screenshot.
This feature highly improves the looks of terrain. However this feature brings quite some troubles with it.
Saberpeak has some great documentations on how 'advanced’ terrain creation works.
http://home.comcast.net/~saberpeak/website/tutorials/part1.html
Textures are projected onto the brush. This normally happens along the z-axis which might cause some texture stretching when the brush is too strongly transformed (e.g. hills/cliffs in 1944 beach)
This can be prevented by projecting the texture along the other axis. However, this needs an extra shader. See saberpeak.

This is not an issue in FATE as it only gives you the brushes anyway (without textures/shaders). If this feature is implemented in EasyGen there is the need to implement some sort of detection script as-well.
In the attached radiant-shot you can see the grey/black squarish textures which basically are the same shader, simply projected along different axis.
The shaders create a visible seam when they meet. That’s how you know when a texture should be projected on a different axis to avoid stretching.
However this is a radiant shot, which means I created all that manually (cliff + shader + blending) and that takes quite some time!
If this feature is implemented in EasyGen there is the need to catch that misallignement somehow and automatically create a seperate shader. (They only differ in one line)

- just read through the saberpeak documentation and you will see what I’m talking about.

#2 Updated by Mateos over 5 years ago

Mmh I looked at your editor screen, so you’re using a different projection depending on how is oriented the brush?

If you use an editor_image different from the actual texture, the compiler will project everything like if it was applied on a flat surface from the top (more or less, to simplify); That’s how SimonOC tutorial is supposed to work (I believe), and you can compare with the same terrain on 1944_huertgen and 1944_huertgen_final2 how smooth are all the transitions between all the different textures, without taking in consideration the projection axis (I even added/forced one just to be close to the Fuel Dump shader).

Well, to sum up, my point/question is: is it really needed to investigate about the axis as for the projection method?

This is only based on my experience (also used this on an unreleased map, I did the terrain for a friend), and you investigated more than I did, and you have a working thing too... heh.

+1 to your point of view about the navigation in the software, nice investigation, thank you

#3 Updated by keMoN over 5 years ago

Have a look at the saberpeak documentation I posted in the comment above.

If you use an editor_image different from the actual texture, the compiler will project everything like if it was applied on a flat surface from the top

That is not correct^^ It would be correct if I had three different editor image for the same texture/shader, which I dont. They all differ in one line: q3map_tcGen ivector ( 0 512 0 ) ( 0 0 512 )
Those numbers indicate the projection. This would be along the x-axis. For z-axis you would need the following: q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 ).
If you projected a texture along the z-axis onto a steep brush it would look like this
If you projected the texture along the correct axis, it looks like this

There is still a visible seam and you also could fix that, but taking in cosideration that ET players don’t seem to be bothered by the horribly streched terrain in some maps, they won’t care about that seam.

//EDIT: But thinking about your statement with simonOC...you’re right, you can put a texture onto a vertical brush and it works...maybe this has somehting to do with the blending-shader (dotproduct)

#4 Updated by Mateos over 5 years ago

Now that you point your point (heh, English very well spoken ) with screenshots, I remember experiencing this on Supply WE, when the cliff was almost vertical... I think I played with the texture size through the shader to limit the stretch, but I can’t remember in which way (increase or decrease), and I was experiencing funky results...

There is probably several ways to achieve this; The best you be to find the simplest way... Now what is needed shader-wise is to define "simplest"

You probably have more time and motivation than me, as I see how much you investigated the question. I experienced with shaders a lot through 3 projects which are over for almost a year, so I guess I’m out on this one... for now!

Anyway; As EG was able to detect the triangles which couldn’t be climbed by the players (with a little error marge), there could be some shader choice based on this, but that would mean hardcoded generation, and no more external templates, or am I wrong?
On the other hand, since it is probably the same for all the iDTech III games, it should’t matter; Or will require some shader history research... heh. Ouch ^^'

Because it’s not only for ET... Will not simplify the thingy >.>

#5 Updated by IR4T4 over 5 years ago

  • Target version set to 1.4.5

Also available in: Atom PDF