Realtime

OVERVIEW

Definition

Deutsch

Als Echtzeitsysteme (englisch real-time systems) werden „Systeme zur unmittelbaren Steuerung und Abwicklung von Prozessen“^[1] bezeichnet, die dafür an sie gestellte quantitativeEchtzeitanforderungen erfüllen müssen. Diese kommen in diversen Technikgebieten zur Anwendung, etwa in der Prozessleittechnik, in Motorsteuerungen, in der Satellitensystemtechnik, in Signal- und Weichenstellanlagen, in der Robotik und in weiteren Bereichen.

Oft besteht die Anforderung darin, dass ein Ergebnis innerhalb eines vorher fest definierten Zeitintervalles garantiert berechnet ist, also vor einer bestimmten Zeitschranke vorliegt. Die Größe des Zeitintervalles spielt dabei keine Rolle: Während bei einigen Aufgaben (z. B. in der Motorsteuerung) eine Sekunde bereits zu lang sein kann, reichen für andere Probleme Stunden oder sogar Tage. Ein Echtzeitsystem muss also nicht nur ein Mess- oder Berechnungsergebnis mit dem richtigen Wert, sondern dasselbe auch noch rechtzeitigliefern. Andernfalls hat das System versagt.

In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware nicht immer realisieren. Daher spricht man auch von „in Echtzeit“, wenn Programme ohne spürbare Verzögerung arbeiten. Diese Definition ist jedoch sehr unsauber. Grundsätzlich falsch ist es, „Echtzeitsystem“ als Synonym für „besonders schnell“ anzusehen. Im Gegenteil, Echtzeitsysteme müssen entsprechende Leerläufe einplanen, um auch in besonders fordernden Situationen ihren Echtzeitanforderungen gerecht zu werden.

English

In computer science, real-time computing (RTC), or reactive computing describes hardware and software systems subject to a "real-time constraint", for example from event tosystem response.^[1] Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".^[2] Systems of this type whose correctness depends on their temporal aspects as well as their functional aspects. Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds. A system not specified as operating in real time cannot usually guarantee a response within any timeframe, although actual or expected response times may be given.

A real-time system has been described as one which "controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time."^[3] The term "real-time" is also used in simulation to mean that the simulation's clock runs at the same speed as a real clock, and in process control andenterprise systems to mean "without significant delay".

Real-time software may use one or more of the following: synchronous programming languages, real-time operating systems, and real-time networks, each of which provide essential frameworks on which to build a real-time software application.

Systems used for many mission critical applications must be real-time, such as for control of fly-by-wire aircraft, or anti-lock brakes on a vehicle, which must produce maximum deceleration but intermittently stop braking to prevent skidding.^[4] Real-time processing fails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of system load.

REALTIME vs RENDERING

PREBAKE vs ENLIGHTEN (Pseudo-dynamic GI)

Guide to Pre-Baking, including Workflow:

http://cgg.mff.cuni.cz/~jaroslav/gicourse2010/giai2010-06-david_larsson-slides.pdf

TEXTURING FOR REALTIME vs TEXTURING FOR NON-REALTIME

Dinge auf die man achten sollte wenn man Texturen für Realtime Assets erstellt.

UDIMS vermeiden, da diese Technik in Games / Realtime nicht verwendet wird. Ist eher eine Technik für Non-Realtime Content wie Cinematics / VFX.
Immer im UV Space 0-1 arbeiten. UVs die über den UV Space gehen werden von den meisten 3D Engines als fehlerhaft angemerkt. Davon abgesehen sieht das Endresultat dann auch fehlerhaft aus. Es gibt aber auch Ausnahmen wie Objekte die eh Tileable Texturen verwenden. z.b. Wände oder Böden usw.
Overlapping bei UVs meiden. Die meisten 3D Engine meckern auch rum, wenn sie Meshes finden die solche UVs haben. Ausnahmen sind natürlich Elemente die sich in einem Asset wiederholen, wie z.b. Schrauben usw.
Immer auf dem ersten UVSet arbeiten, da 3D Engine meistens ein zweites UVSet automatisch mit neu gepackten UVs für Lightmapping, Occlusion Maps usw erstellen.
UVs sollten sauber sein und kein unterschiedliches UV Skaling innerhalb eines Meshes haben, damit die Texture auch überall die gleiche Qualität hat.
UV Flipping vermeiden. Ist schlecht für Normalmaps usw. Generell ist es schlecht geflippte UVs in seinem Mesh zu machen. BÖSE BÖSE!!
Eine Main UVset / Texture pro Assets oder Texturen / UVset pro Shader. Shader und Texturen sind kostbares Performance Gut, daher sollte man versuchen den Einsatz so effizient wie möglich zu handhaben. Das heisst, zuviele Shader mit zu hohen Texturen können echte Performance Killer sein.
Texture Quality vs Performance vs Graphiccard Memory. Die Texture Auflösung sollte nicht höher sein, als die, die man wirklich für ein Asset braucht. Heißt eine kleine Goldmünze von 4x4 cm braucht keine 8192x8192 Texture. Da reicht eine 128x128 > 256x256 Texture vollkommen aus.
Lightmapping UVs werden auf Basis des erste UVSets erstellt. Das heisst, es werden keine komplett neuen UVs für Lightmapping verwendet, sondern es wird das erste UVSet genommen und die Engine macht ein Repack auf das zweite UVSet. Sind die ersten UVs schlecht, kann dadurch auch die Qualitat der Lightmap leiden.
zerhackte UV Shells meiden. Heisst durch ein Automatic Mapping können schnell einzelne UV Shells entstehen oder sogar einzelne UV von Polys irgendwo rum UV Space rumfliegen. Die UV Shells so gut wie möglich zusammen fassen. Wichtig für die Lightmap UVs. Es versteht sich auch von selbst das man seine UVs wie Gold behandelt. :)

Texturing workflow for realtime content

http://blog.teamtreehouse.com/asset-workflow-game-art-texture-mapping

TEXTURING WITH SUBSTANCE

Tutorials die man jedem, der wirklich ersthaft mit Substance Painter arbeiten möchte, nur ans Herz legen kann.

Substance Painter

Substance Painter Tutorial - Texturing for Beginners : Course Overview

Model Preparation for Substance Painter

Substance Designer

Tutorials coming soon..

UNITY3D

Jan 2015: Pros and Cons:

Pros:

Excellent balance of ease of use and power.
Unmatched platform support.
Performance scales extremely well from simple games for low end mobile to complex games for high end consoles
Built in physical based rendering and extendable rendering pipeline all very high end graphics performance.
Many robust built in features like Occlusion culling, AI navmesh generation, content streaming, and particle systems
Workflows support 2D 3D and hybrid games effortlessly.
C# is an expressive and powerful programming language that is relatively easy to learn.
Solid Content pipeline makes it near effortless to bring in content from a huge variety of tools.
Built in Mechanim animation system is very powerful, lets you drive any value with animation.
Extremely robust asset store has many useful add ons and content and also is a potential revenue stream for developers.
Huge, active, engaged community fascilitates finding help, answers, and teammates.
Active development sees bugs regularly fixed and new features regularly released.
Out of the box VR support.
Royalty free licensing model
Full feature set totally free until you earn $100K revenue in one year.
Useful services like Unity Ads, Unity Analytics, and Unity Cloud Build built right in.

Cons :

Annoying subscription model has additional cost for mobile.
Closed source without extremely expensive source code license.
Stuck on outdated Mono 2.6 runtime, lacks useful newer C# features and .Net compatibility
Antiquated garbage collection because of aforementioned Mono 2.6 can cause performance hitches and requires careful optimization.
Sometimes lackluster implementation of built in features (mobile keyboards Unity rlly?)
Version control is clunky to use due to meta files creating multiple issues, Like deleted folders constantly coming back. missing or broken meta causing references in scenes being lost.
Scene and prefab merging challenges make working on larger teams or several people working on the same scene unwieldy and difficult. This is a show stopper for many larger teams.
Asynchronous content streaming is janky, doesn't work properly with other features like occlusion cullin, terrain, navmeshs, and light mapping. Severely limits ability to make large open worlds without extensive custom architecture (and probably source code access)
Unityscript (fake JavaScript) is a dead end that many developers waste time with.

UNREAL

Getting started with VR in Unreal4

http://www.tomlooman.com/getting-started-with-vr/

UNITY vs UNREAL

Side-by-side picture comparison:

https://www.quora.com/What-are-the-main-pros-and-cons-of-Unity-3D-and-Unreal-Engine

From 2015:

Unity:

Supports 21+ platforms (PC, Console, Mobile, Web)
Well documented
Loads of official & community tutorials out there
Easy for programmers, Easy for designers
Great for building any kind of game

Unreal:

Supports ~6 platforms (Mainly PC+Consoles)
Has a history of being one of the nicest looking engines
So so documentation
Drag-drop tool for basic interaction
Lots of tutorials if you are a designer, very little for coders
Built from a First Person ShooterPS, which makes it a lot harder to do non FPS games

REALTIME AND MOBILE

Brief Overview:

http://www.mobyaffiliates.com/blog/ios-android-mobile-game-development-tools-frameworks-engines-resources/