Awesome! This engine just keeps getting better

actually, it looks like it could really use motion blur - but that's an awesome concept.

Controling them by texture? That's an awesome (!!) feature. Nice work!!

any news?

"any news?"

I've just been researching and implementing PRT. I actually decided NOT to use prt because even though it supports dynamic lights, it does not support dynamic geometry. Also, it has very bad "reviews" from other programmers and is actually not fast at all. Instead I'm using lightmaps with spherical harmonics for light transfer. The results are visually the same, however, objects can be dynamic and the process is so fast that it hardly makes any noticable difference in framerate at all. The only downside is that the lightmaps do not change with dynamic lights, however, because Iridium has very fast dynamic light rendering and computes light with both techniques, there is no problem.

I actually made a PRT script that worked but it ran at only 30 fps without anything else (plus PRT won't cast shadows from dynamic objects properly!). Another problem was using PRT in rooms that where very large or open. Because it is computed in 3d space, it suffers in larger or higher-resolution situations (allthough geometry complextion has no effect because its pre-computed). Overall I was very disapointed with the results.

The new harmonics script allows entities to lookup lightmap values similar to the A7 engine PRV. However, I use multisampling and advanced shader effects to move the lightmapping from a cheapper lighting method to a method that adds convincing global illumination when combined with fully dynamic lighting. The method is extremelly fast for static geometry and very fast for dynamic objects.

I also created a script to generate indirect illumination only lightmaps. This allows you to combine pre-computed radiosity lighting with real-time direct and specular lighting from the same lightsource. You can also render area lights with this.

Another improvment I made was dynamic tonemapping. The beta I released had a huge bug that prevented the tonemapping from working. Now, Iridium renders in full 64-bit HDR with 1000x1000 multisampled tonemapping with dynamic exposure control. This helps convey colors and light intensities previously impossible. You can even take screenshots in .hdr format to preserve the entire scene's color values. In addition, I created a dll for rendering to screens that support HDR values such as LED and Plasma televisions. The results are beyond stunning!

I also added high-resolution rendering up to 1080p as well as options to render in scanline or progressive execution.

-Mike-

Wow!

What edition of the directx sdk are you using? Mine's quite outdated (august 2007), and (since i've got such a slow internet connection) I was wondering whether there is any great improvement in newer editions.

64-bit HDR?! Never heard of that before.. in the SDK it's only 32.


So the values are stored in an Octree-type structure? What type of FPS are you getting?

Can't wait for release!

screeeeenshots! I want screenshots!
Sounds good what you're doing!
So what is still on the to-do list before the next beta?

I have the march 2009 directX sdk (v 9.26.1590).

The 64-bit HDR is a custom feature I made so that you can render scenes that have dozens of times difference in gamma. It is especially nice for creating bright flash effects so that the gamma adaption takes an appropriate amount of time to stabalize (such as a flashbang grenade).

For the radiance transfer, I pre-compute the directions of incoming light as a quadratic formula (to compress several light directions into one value). I also store indirect attenuation but not color. Direct illumination is so cheap that you can just create dynamic lights throughout the level to add color and direct illumination. (only indirect illumination is stored).

During run-time, the data is efficiently extracted and combined with bump and parallax-occlusion mapping for a seamless rendering style. The pre-computed light direction also creates specular highlights.

The framerate hit is redundant because unlike PRT, the heavy lighting calculations are moved from online to offline. That is why the data is stored in spherical harmonics. The decompressions and application of the data is extremely fast and simple. It only takes a few operations on the CPU and a few on the GPU.

-Mike-

What is still on the "to-do list?"

I have to re-write the API to support functions regarding the radiancve transfer functions. I have to fix the shadow mapping which has some sort of problem with stitching when using cubemaps. I also have to add some sort of pre-computed shadow filtering because I don't have the option of blurring shadows after generation because the lights are all rendered in a single pass together.

-Mike-

hey,
Im going on vacation today (July 19th) and I'll be back in one week. I'm not taking any emails, messages, or post thingies until I'm back. Have a great week - Mike -