[INFO] Development Journal

User avatar
Creavion
Godlike
Posts: 4497
Joined: Sun Feb 17, 2008 7:23 pm
Personal rank: About to be non-act.
Location: Germany, Lower Saxony

Re: [INFO] Development Journal

Post by Creavion » Tue Mar 06, 2012 10:17 pm

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! :ironic:
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. :mrgreen:

@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.
About to be non-active
My very last UT map project: CTF-FacePalm (tropical CTF-Face remake)
Why do I leave? click here
What I want to do next: Joining an UDK team (uncertain however) and improve 3D modelling and texture editing skills
Thanks to those who visibly supported me until/at the end!
My reactivated account on indiedb.com.

Higor
Godlike
Posts: 1819
Joined: Sun Mar 04, 2012 6:47 pm

Re: [INFO] Development Journal

Post by Higor » Tue Mar 06, 2012 11:07 pm

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.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
Shadow
Masterful
Posts: 719
Joined: Tue Jan 29, 2008 12:00 am
Personal rank: mad scientist
Location: Halle (Saale), Germany
Contact:

Re: [INFO] Development Journal

Post by Shadow » Fri Mar 23, 2012 1:20 pm

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

Image Image Image


Download

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

User avatar
UT Sniper (SJA94)
Masterful
Posts: 610
Joined: Thu Jun 24, 2010 10:35 pm
Personal rank: noob programmer
Location: England
Contact:

Re: [INFO] Development Journal

Post by UT Sniper (SJA94) » Fri Mar 23, 2012 11:42 pm

Great work. :)

User avatar
Dr.Flay
Godlike
Posts: 3284
Joined: Thu Aug 04, 2011 9:26 pm
Personal rank: Chaos Evangelist
Location: Kernow, UK
Contact:

Re: [INFO] Development Journal

Post by Dr.Flay » Sun Mar 25, 2012 12:22 am


Higor
Godlike
Posts: 1819
Joined: Sun Mar 04, 2012 6:47 pm

Re: [INFO] Development Journal

Post by Higor » Sun Mar 25, 2012 12:38 am

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

Very nice.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

Higor
Godlike
Posts: 1819
Joined: Sun Mar 04, 2012 6:47 pm

Re: [INFO] Development Journal

Post by Higor » Fri May 04, 2012 5:39 pm

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).
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
Shadow
Masterful
Posts: 719
Joined: Tue Jan 29, 2008 12:00 am
Personal rank: mad scientist
Location: Halle (Saale), Germany
Contact:

Re: [INFO] Development Journal

Post by Shadow » Tue Sep 04, 2012 11:04 am

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.

Image

Higor wrote: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.
Image

User avatar
Feralidragon
Godlike
Posts: 5247
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: [INFO] Development Journal

Post by Feralidragon » Tue Sep 04, 2012 1:27 pm

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)?

User avatar
Shadow
Masterful
Posts: 719
Joined: Tue Jan 29, 2008 12:00 am
Personal rank: mad scientist
Location: Halle (Saale), Germany
Contact:

Re: [INFO] Development Journal

Post by Shadow » Wed Sep 05, 2012 7:04 am

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.
Image

User avatar
Feralidragon
Godlike
Posts: 5247
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: [INFO] Development Journal

Post by Feralidragon » Wed Sep 05, 2012 11:04 am

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 :tu:

User avatar
Shadow
Masterful
Posts: 719
Joined: Tue Jan 29, 2008 12:00 am
Personal rank: mad scientist
Location: Halle (Saale), Germany
Contact:

Re: [INFO] Development Journal

Post by Shadow » Wed Sep 05, 2012 7:27 pm

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!
Image

User avatar
Feralidragon
Godlike
Posts: 5247
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: [INFO] Development Journal

Post by Feralidragon » Thu Sep 06, 2012 11:14 am

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?

User avatar
Shadow
Masterful
Posts: 719
Joined: Tue Jan 29, 2008 12:00 am
Personal rank: mad scientist
Location: Halle (Saale), Germany
Contact:

Re: [INFO] Development Journal

Post by Shadow » Thu Sep 06, 2012 4:47 pm

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 :D
Image

User avatar
Feralidragon
Godlike
Posts: 5247
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: [INFO] Development Journal

Post by Feralidragon » Thu Sep 06, 2012 6:01 pm

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

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.

Post Reply