game components library
- 3D Audio
- Stereoscopic rendering
- Networking
- LOD scheme
- Impostors
- Physics for static objects
- Ragdoll for characters
- In-Game Level Editor
- Postprocessing Pipeline
- Night-Day Light cycle
- HDRI pipeline
- Tessendorf's Realistic Water
- Outdoor Light Scattering
- Ambient Occlusion
- Global Illumination technique (e.g. Radiosity, Photon Tracing, ...)
- ....
We could go on for another 3 pages. Any particular reason for this excercise ?
- Postprocessing Pipeline
which effects specifically?
We could go on for another 3 pages.
LOL. yeah, i know!
Any particular reason for this exercise ?
i've been making games on and off for a long time. this is the 3rd time i've re-started my company. each time i do, i end up with a library of generic game components that i use again and again in title after title. in the past i've actually sold these as products.
its time to do some work on the current library.
the items i listed are already in the library or exist in other code that can be converted for generic use by the library. everything except skinned meshes.
in the original list i forgot sound effects playback and music playback. those have been in libraries i've made in the past, but have yet to be added to the current one.
so please, keep the list coming, odds are i'll have to build all these things sooner or later.
while we're at it i suppose we ought to add the holy grail to the list, even though todays PCs still can't quite do it:
realtime raytracing.
one of the things that prompted this exercise is that i've come up with some new components that REALLY speed things up in the area of graphics and collision checks. and it made me wonder if there were any types of components i wasn't aware of. you know how it is, the best way to do things in games is a constantly shifting target as hardware improves and old algos can be done in realtime, and new algos are created. every once in a while you have to stick your head up from your cubicle and take a look around and see what's new.
It seems to me that one of the biggest paradigm changes of last few yrs is the ability to run the CUDA / OpenCL code for preprocessing of the level data during loading. Especially, if you have some computationally expensive operations on a large terrain, it is better to offload the poor CPU with its measly 4 cores and let the GPU with 1000 cores sweat.you know how it is, the best way to do things in games is a constantly shifting target as hardware improves and old algos can be done in realtime, and new algos are created. every once in a while you have to stick your head up from your cubicle and take a look around and see what's new.
The loading times can be drastically reduced this way, especially if you have a lot of content generated procedurally (namely large-scale terrain features, but almost anything else - calculating normals/binormals/tangents, precomputed visibility, octree,...).
You can't live long enough to implement all of them. But you could start with few basic ones:Posted Today, 01:08 PM
VladR, on 02 May 2013 - 11:26, said:
- Postprocessing Pipeline
which effects specifically?
- Bloom
- Ambient Occlusion
- Bokeh (DoF)
- Radial Blur (GodRays)
- Motion Blur
Physics for static objects
i have the gravity modeling code, but not the stacking of objects.
- Impostors
by this i assume you mean the texture generation part, as targets can already be drawn as 2d billboard, 3d billboard, single mesh, multi-mesh static model, multi-mesh limb-based animated model, and when i add it, animated skinned mesh.
i forgot animation player manager on the original list. got that too already.
It seems to me that one of the biggest paradigm changes of last few yrs is the ability to run the CUDA / OpenCL code for preprocessing of the level data during loading. Especially, if you have some computationally expensive operations on a large terrain, it is better to offload the poor CPU with its measly 4 cores and let the GPU with 1000 cores sweat.
The loading times can be drastically reduced this way, especially if you have a lot of content generated procedurally (namely large-scale terrain features, but almost anything else - calculating normals/binormals/tangents, precomputed visibility, octree,...).
funny you should mention that.
the recent "breakthrough" i had on the graphics on my project was in relation to just such a problem.
the solution allows me to have a HUGE (2500 mile x 2500 mile) procedurally generated, persistent, modifiable world with scene complexity on on the order of 15,000 meshes for the high LOD terrain alone after frustum culling. framerates are currently running rock steady at 62.5 fps. no shaders. dx9 fixed function. i still can't believe how fast it is.
so that component is definitely going into the library. it may be overkill for simple projects. i suspect it may be possible to take some of the components and string them together to make component sets that provide simple high level black box functionality, while the component design of the API lets you use just what you want, instead of having to embrace an entire "engine" or particular development paradigm.
for example, stringing the target drawing, frustum culling, and drawlist components together.
two more things for the list i forgot that are already in there:
camera
lights
- Night-Day Light cycle
i've got the code, what would you want the API to look like?
time of day in ==> lighting scale factor (0-1) out ?
or am i not following what you mean?
the variables for the model include time of sunrise, time of sunset, and current time as input. light intensity and direction are the output. sunrise and sunset times are currently hard coded but could be made variables for a generic version for the library.
- Night-Day Light cycle
i've got the code, what would you want the API to look like?
time of day in ==> lighting scale factor (0-1) out ?
or am i not following what you mean?
I meant Practical Analytic Model for Daylight:
I meant Practical Analytic Model for Daylight:
did you notice this part?
"The implementation of the model was not carefully