Common updated standard Engine.u

A refuge for those migrating from the fallen DXEditing.com and a place for general discussion relating to Deus Ex editing (coding, mapping, etc).
Post Reply
Hanfling
MJ12
Posts: 406
Joined: Sun Oct 04, 2009 6:54 pm

Common updated standard Engine.u

Post by Hanfling »

While I'm no fan of modifying vanilla code package as this especially in case of the DeusEx.u leads to a huge amount of incompatibilities and even prevents the usage of native subclasses of native classes out of DeusEx.u, because it's common to oversize them.

However on the Bitmap and Texture class there is a decent amount of space left blank due to alignment, so one could add serveral byte (or enum) variables to it. One of the most desired features would be to be able to set wrapping mode for textures, especially using clamp for certain textures as especially anisotropic filtering can result in more quite a few pixel values fetched off the wrong side and thus causing annoying lines at the side of textures. Especially some fractal texture like flames should ideally have UWrap=VWrap=TEXW_Clamp set, so there is never some wrapping around for those.

Code: Select all

var(Texture) const enum ETextureWrap
{
  TEXW_Repeat, // That's whats currently done (GL_REPEAT).
  TEXW_Clamp, // Thats what i desire (GL_CLAMP_TO_EDGE).
  TEXW_MirrorRepeat, // Probably has it's uses though (GL_MIRRORED_REPEAT).
  TEXW_MirrorClamp, // Probably has it's uses too (GL_MIRROR_CLAMP_TO_EDGE).
} UWrap, VWrap;
The big advantage is that one doesn't need to introduce any new classes (especially you won't need extra subclasses for FireTextures, etc. etc.), old texture packages stay compatible with the new updated Engine.u, while you won't get more then a warning when loading it with an old Engine.u, though if you resave the texture packages with the old Engine.u, these properties get lost.

On the render device side, you can just easily apply/fetch these settings when unpacking the texture. Afaik they would even be initialized as zero when using the old Engine.u, and as TEXW_Repeat equals zero which is the old behaviour nothing would break. However, one can basically do a check once in the renderdevice if the properties do exists (and optionally also query their offset).

Another interessting idea would be to introduce a Type property to add support for non 2D textures, especially cube map textures (and use these to do proper enviroment mapping).

Code: Select all

enum ETextureType
{
  TEXT_2D, // 2D texture.
  TEXT_3D, // 3D texture.
  TEXT_1D, // 1D texture.
  TEXT_CubeMap, // cube map texture.
} Type;
As for generating cubemaps, it should be rather straight forward to add a command for taking the required six screenshots ingame and saving them, and would certainly look on the helicopter in the Mj12 hanger. :)

In any case, Rajada and me will use these in our Nerf 300a update, maybe I can show some proper environmapping screenshots soon. :)

So any thoughts on having a new standard Engine.u?
I demand my DXE User ID back. Launcher for DeusEx, Rune, Nerf, Unreal & Botpack. HX on Mod DB. Revision on Steam.
daedulas
Thug
Posts: 33
Joined: Sat Nov 03, 2007 4:06 am

Re: Common updated standard Engine.u

Post by daedulas »

I'm rather curious as to what cubemapping looks like in UE1.
Still got some screenshots of it?
Hanfling
MJ12
Posts: 406
Joined: Sun Oct 04, 2009 6:54 pm

Re: Common updated standard Engine.u

Post by Hanfling »

Haven't yet used other than 2D textures.

The old PF_Environment/bMeshEnvMap actually does roughly Sphere Mapping at the vertex level. Implementing this in the fragment shader (with proper projection) looks like that:

https://track3.mixtape.moe/vnktmy.PNG
https://my.mixtape.moe/gadivc.PNG

So one of ideas was that one could also support cubemaps for that, but haven't pushed that further. Currently I'm more interessting to use the Type to be able to use arrays textures for AnimNext linked animated textures, which would allow to make things more efficient. (Currently for things like DT_SpriteAnimOnce each time it is rendered all AnimNext linked textuers are counted, and afterwards again looped over to fetch the right one, so storing them in arraytextures would allow to skip that and also enforce that each of the individual frames has the same size, which is resonable to guarantee for culling, so the actual used texture doesn't need to be figured out at that point, etc.)

However doing the Sphere Mapping at the fragment level also doesn't come without issue, for shieldbelt-ish effects like the double damage in Nerf you get a mix of non distorted parts and (like before) distorted parts which isn't that big suprise, given the fact that the source texture isn't anything like a Sphere Map.

My current idea is to try out so called Triplanar mapping: http://www.martinpalko.com/triplanar-mapping/ to get rid of the distortions. etc.
I demand my DXE User ID back. Launcher for DeusEx, Rune, Nerf, Unreal & Botpack. HX on Mod DB. Revision on Steam.
Post Reply