[INFO] Development Journal

[Creavion]

Gothic is the greatest shit ever! From no other game I learned soo much about terrain and landscape design. For me it is the best german production which makes me at least in this point proud to be German!
Whatever I built, buddies always "complained" "once again, it looks like Gothic".
Many years ago Shadow, some other people and me attempted to make a single player mod for UT called Unreal Skaarj Unleashed (well the thing failed^^), however I guess nearly all of us played at least gothic but most of us loved it.
Our scripter at that time even included on my request a cheast (also modelled an own "bloodfly" although Unreal already had a big fly) which can be opened as like in Gothic, we just loved this shit and a rather crazy modeller wanted to convert the scavenger for UT. It surely was a crazy and "gothic" time.

@Your project: Apart from the fact you might piss of Piranha Bytes, it would be way too weird to imagine to find a dispersion pistol instead of a rusty sword near the forgotten mine. But hey, that thing would be already enough to kill snappers (distance shot and run way, repeat first steps until they have been killed).

Actually you can use 227s static meshes for exactly this. Regarding a dev build dots improved them heavily to version 3. I had no performance problems at all with this.

However you won`t be able to reach many people there. The Unreal community is mostly really uhm "mixed" up, like already mentioned and the most important sp mods (still in development) [Firestorm, The Chosen One and RD] would be playable for UT as well anyway, so no real 227 stuff again. No matter how good oldunreals enhanced engine is, either nobody is able to use them or most just want to keep compatibility with UT. UT always wins. Content vS Engine.

[Higor]

Exactly my thoughts, the original idea was to use the SDK on UT, and in some point it still is.
Well, the little code I made is 99% percent compatible, and exporting a map to T3D with some batch modifications, PAM! it's in UT now. So there should be no problem changing 227h > UT SDK once both (mine and SDK) are advanced enough.

Leaving the mod aside, playing a DM on the Gothic map would be the shit.

About static mesh LOD's, awesome idea, gotta give credit the 227 guys for that. You can actually create a series of low poly meshes and use them as LODs in the same actor.
Using that feature properly, you could theoretically split a huge terrain made of NxN blocks with over 30 million polys total, and thanks to that, the engine would only render 30k as much.
It's also a good idea because meshes don't occlude like BSP does, so mappers either have to LOD them, or hide them using the old VisibilityHeight and VisibilityRadius method which becomes extremely useful on full static mesh maps.

I never tried the UnrealEngine 3 SDK, but it surely has those features, which makes the creation and rendering of huge terrains possible.
The main problem I faced on Gothic, is that terrain is as optimized as possible, with perfect texture placement/mixing (up to 10 unique textures in a mountain), so making a LOD of those premade terrains becomes impossible without a severe loss of quality and visible holes at the distance.
I resorted to special occluders I coded myself that you can use to check player location (zone checks, cylinder checks, plane checks, sphere checks, 3d elypse checks, trace, moving trace between player and the sides of a cylinder, etc) and if conditions are met, meshes become visible or invisible.
Using that I managed to reduce onscreen polycount from 45k to 25k on some locations, but it isn't enough 18k is the ideal maximum since in a possible final release characters and other things will be rendered as well.

[Shadow]

UTSDK February 2012 Beta Release

So finally here it is. The next new and fresh release of the Unreal Tournament Community SDK. This month's release comes with a huge update for the Material System adding new Materials like TexRotators and TexEnvMaps! On the other hand I implemented a lot of the C++ rendering functionality on Unreal Script Level (native functions) and finally added full Quaternion Support.

More good news: I reimplemented Projectors and optimized them and fixed some rendering bugs concerning the new Blending Styles. There're also finally 2 read-to-use Example Packages (sdkSandbox and sdkSandboxMaterials) showing example content including Materials, Static Meshes, Projectors and Emitters.


New Features

• added: new Sprite Class „sdkQuad“ - a Sprite with free rotation and no camera alignment
  
  
• added: new Texture/Sprite Rendering Functions
  - DrawRotatedTile (a freely rotatable Texture Quad without camera alignment)
  - DrawBeamTile (specialized function for drawing texture beams and sparks)
  
  
• added: new Material Classes and Texture Modifiers
  - TexEnvMap
  - TexSphereMap
  - TexPanner / TexEmissivePanner
  - TexRotator / TexEmissiveRotator
  - TexScaler / TexEmissiveScaler
  - TexOscillator / TexEmissiveOscillator
  - Emissive Material
  - TexCombiner
  
  
• added: new Packages "sdkSandbox" and "sdkSandboxMaterials"with Tutorial, Test, Example Contents and Classes
  - ready-to-use Classes
  - Example Emitters and Particle Systems
  - Example Projectors
  - Example Materials
  - Example Static Meshes
  
  
• added: new Datatypes (C++ and Unreal Script)
  - ColorRange, a randomized color value
  - FloatRotator, a floating point rotator
  - Vector2DRel, a 2D vector with a relative scaler
  
  
• added: new Iterator Functions
  - CollidingActors – iterates through all colliding Actors (visible or not visible)
  - AllObjects – iterates through all objects in a level
  
  
• added: new Primitive/Sprite Rendering Functions (Unreal Script)
  - Draw3DArrow
  - Draw3DPlane
  - Draw3DFrustum
  - Draw3DBox
  - Draw3DSprite
  - Draw3DCorona
  
  
• added: Full Quaternion Support
  - uses FPlane struct, but operations inside functions equals real Quaternions
  - globally supported on Unreal Script Level
  - globally supported on C++ Level
  
  
• added: new Canvas Functions
  - DrawTile2 (like DrawTile, but supports new Blending)
  - DrawRotatedTile (draws a spinning texture tile)
  
  
• added: new Color Functions
  - ColorLerp, smooth linear Color Interpolation
  - ColorSmerp, smooth non-linear Color Interpolation
  - VectorToRGB, RGBToVector – conversion between vector (in 0.0/1.0 range) to color
  
  
• added: Color Sprite Preview for sdkLight

Fixes/Updates

• updated: recoded and updated Material/Texture System
  
  
• updated: completely recoded Texture Projectors, merged Decal / Plane Projectors into one Class
  - supports new Texture Blendings (introduced Build 335)
  - U/V Scaling
  - U/V Tiling
  - Dynamic Color
  - Projection Fading
  - Projector → DynamicProjector → DistanceProjector → ShadowProjector
  
  
• updated: all Texture drawing Canvas functions have been updated to support new Blending Styles
  
  
• updated: moved all Iterator Functions from sdkLevelInfo to sdkActor, static functions now (global)
• updated: moved all Color Functions from sdkCanvas to sdkActor
  
  
• fixed: serious Render Bug when changing new Blending Styles (BSP changed blending too)
• fixed: incorrect native function IDs in sdkActor.uc
• fixed: internally corrected HLS to RGB color conversion (lensflares, coronas, lights, canvas)

Media




Download

UTSDK February 2012 Beta (Build 359) - 29 MB @ ModDB
UTSDK February 2012 Beta (Build 359) - 29 MB @ Mediafire (Mirror1)

[UT Sniper (SJA94)]

Great work.

[Dr.Flay]

http://files.myopera.com/dr-flay/unreal ... 2-BETA.zip Another fast mirror

[Higor]

Quaternion support and texture panner, one step closer to moving Gothic project from OldUnreal to this.

Very nice.

[Higor]

Another thing I had in mind, is it true that native function's parameters are passed in a buffer then casted again?

If that's so, is it possible to either alter the parameters or the return value on c++ level to create a typical ReinterpretCast() function?
Conserving bit values by manually encoding/decoding floats from/to integer values is kind of a slow operation (and tedious to code, I know because I did it).

[Shadow]

First update for Months! Yeah.. I know. I updated and overhauled the (Static)Mesh Render System completely, which resulted in a much more stable and flexible Mesh Renderer. This also and finally allows me to make real mesh-based Emitters and Effects like Mesh Emitter, Beam Emitters and so on.

New Features include: dynamic Mesh Color (Custom Color, Color Interpolation/Fade), Lighting Options, Gouraud/Flat Shading Options (Lighting), Static Animation Sequences, support for new Texture Blend Modes (some known from Unreal Engine 3), Vetrex Sprite Support.

Another thing I had in mind, is it true that native function's parameters are passed in a buffer then casted again?

If that's so, is it possible to either alter the parameters or the return value on c++ level to create a typical ReinterpretCast() function?
Conserving bit values by manually encoding/decoding floats from/to integer values is kind of a slow operation (and tedious to code, I know because I did it).

is this that much important? I mean most conversions are kinda slow


THE f*cking clew concerning these new meshes was: Normally you can't render a mesh without a passed actor instance! Thanks to epic for making this that much difficult. Finally I bypassed that issue and now I may render meshes where and how I need them.

[Feralidragon]

Curiosity question: when you say "Finally I bypassed that issue and now I may render meshes where and how I need them", you mean rendering the same mesh several times or rendering different meshes from a single actor instance?
Also, do these meshes support animation (vertex and/or skeletal)?

[Shadow]

A good question mate!

Be it DrawMesh, GetFrame or DrawActor, all these functions need an Actor to be passed. Internally these functions grab the stats of an actor like location, rotation, scaleglow, drawstyle etc. to draw a mesh according to an actor's settings - so good so far. But when it comes to rendering a mesh with own passed stats like described previously WITHOUT passed actor then this fails completely. Epic simply didn't take into account that somebody else wants to render stuff without an actor representing it - there never was any for it. That's where actor components and inline classes came in handy in later Unreal Engine generations.

The meshes of the Static Mesh Actor and the mesh-based Emitters only support changing the initial shape of a sequence like in the Mesh Browser (without hitting the play button), since their vertex state shouldn't change no animation is allowed. I could rewrite the existing Epic DrawMesh functions (publicly available) and again swap their GetFrame function with mine.

[Feralidragon]

Hmm, interesting. I know that at least via UScript, I can render different meshes with animation support using just the canvas and just 1 actor instance (change actor mesh, render, change again, render another mesh, etc, pretty fun actually), thus I was even considering build a pure UScript particles/weather system and just using 1 single actor instance for it and something to be able to render on canvas (like a auto-loaded HUD mutator).
The only limitations of this though is that it can only animate pre-defined sequences (the kind you can run "manually" by just adjusting AnimFrame and AnimSequence), as it fails completely in tweening animation (the animation just gets f*cked on tween lol), and the ZHack property of the render has to be set to False to be rendered properly in the world (which causes the Redeemer to overlap the HUD, as well the FlakCannon a bit in widescreens, but they can be fixed internally with some adjustments in their drawscale and render offset, so not a biggie really).

So essentially, the reason I made the question in my previous post, is that I can already make in UScript what you did with C++, with perhaps a bigger resource cost (since C++ is much better to do such things), but still doable and usable for most situations without the cost of spawning an actor per particle.

But of course, if someone wants the ability to change the mesh overlay color on runtime, XYZ scales and all that, then your functionality is perfect and preferable (although even for these there are less conventional and painful solutions in UScript and a model program).

Good job btw

[Shadow]

That whole thing with the canvas and uscript didn't turn out for me for the reasons already given by you and beyond. I simply always wanted emitters that can be edited in realtime with preview in the editor without any actor (except emitter) and with high performance boost (static meshes). I'm even planning a similar mini-editor (with curves, stats etc.) like in Unreal Engine 3 or 4 as soon as my whole new UI system is up. This makes really sense considering complex features like scripted colors and timed size scaling, physics etc.

Always a pleasure to talk with you about these delecate features and mechanics!

[Feralidragon]

Realtime editing.... one of the things I miss all the time when doing a map (although the last map I did was back in 2010 lol, so...). But yes, doing it in C++ adds a whole new set of possibilities and ease of use.

As for the curves editor, that seems a really interesting idea. I don't know if you use Photoshop frequently (it's likely you do), but when doing blending you have stuff like satin, glows, shadows, 3d effect, etc, and they have also some sort of curves editor to adjust the intensity of those effects from one side to the other of the image you're doing.
The thing is, they have already good preset ones in such a way that you rarely need to mess and create a new curve, so my question is: are you planning to have some sort of presets and the ability to save/load custom curves (even to share with other devs) in that editor?

[Shadow]

Yes, yes and again yes^^ I know these filters and I intend to allow all settings inside this mini-editor to be saved be it directly into a chosen emitter or as external file (txt/ini) wouldn't make much sense without that

[Feralidragon]

Trust me, I saw lots of things which didn't make sense.... some of them were mine lol

Nice. Now a serious suggestion: if you want to get anywhere with this SDK, there are 2 things which are a must imo:
1 - Auto-update/auto-patcher;
2 - Web support (API).

In short, the SDK is looking great in each update, but for someone to start developing more seriously on this I think you need to give the final user the possibility to auto-patch the SDK with a single click, and the final game itself as well (since this SDK is best used in TCs and not simple online/offline mods, it would be cool to have the essential features a game nowadays has: if the developer makes a patch, the game auto-patches, if the developer has news, then the launcher or the game should show these news).

Also web support is a must: building an API to communicate with a web server, using JSON perhaps, can lead the game to save stuff remotely in a database, and also retrieve. Think for example online authentication or any game with RPG elements.

I say this because honestly I am not seeing anyone even using the SDK for just mods or other stuff which aren't worth the trouble for the amount of active players, but Total Conversions (aka new games) would make a lot more sense and without all the complexity AND hardware requirements other SDK's have (*cough* UDK *cough*).
Also, make the web requests latent functions (for some reason Epic thought that they could make a HTTP request to a web server in a single game tick...), since they can take long or not getting a response at all and time out, thus being preferable to be a latent function so the game does not freeze while doing this.