Next MDK?

[scott]

Got any sort of release date for the next material dev kit?

[Carsten]

Hi Scott,
yes, good question, the anwer to which is multi-part:

• I'm not calling this MDK (material dev kit) anymore, but SDK (software dev. kit) instead. Quasi nobody knows what MDK means, while SDK has often been the first spoken word for most newborns these days.
• My current plans are to not separate Ca3DE demo and SDK releases any longer, there will only be one single file that contains all the demo and the SDK files combined. This has many advantages, because 99% of the files overlap anyway, and so the download volume roughly halves for those who want to have both the Demo and the SDK. Moreover, manually merging the Demo and the SDK has always been a task unintuitive and error-prone for most users.
• Publishing Release Candidates worked very well for the February 2007 demo, and so I'm currently extending this to the newly combined releases. You can download the current RC of the new combinbed release at http://carsten.ca3de-community.de/Ca3DE-Combi-RC2.zip

Please let me know what you think about it.

[scott]

Well I finally got it down.

So far I have only tried a simple room with only 1 or 2 light sources at various quality levels and I have to say I'm incredibly impressed with the lighting quality. Your augmented lightmap technology is brilliant. I already knew this from the demo map but its better to try it out yourself.

Where did you get the idea for the augmented lightmaps? I've never seen this sort of thing before.

Cawe is nice and stable as well. Compiling from a menu is a great time saver.

This is awesome I cant wait for the LUA entities, I may actually be able to learn some scripting.

I've been wondering, whats happening with the spherical harmonic lighting?
Are you still working with it or have you scrapped it? I've been dying to see it in action ever since I discovered CA3DE. If you could find it in your heart to just whip up a simple box room with some pillars and a moving light source I would be eternally grateful.

[Carsten]

Your augmented lightmap technology is brilliant. I already knew this from the demo map but its better to try it out yourself.

Great to hear that - for the feedback.

Where did you get the idea for the augmented lightmaps? I've never seen this sort of thing before.

Well, on the one hand, there is a similar technique known as "Deluxe Mapping" that apparently somebody build into the Q3 lighting compilers, but only few Q3 derivatives make use of it. Moreover, I was revising CaLight pretty thoroughly anyway in fall and early winter last year, and it was a natural conclusion at some point: Augmenting the lightmaps in the way I did provides all the same input that is normally associated with "dynamic" (Doom3-style) light sources, but based on Radiosity computation results.

Cawe is nice and stable as well. Compiling from a menu is a great time saver.

Again, good to know that.

This is awesome I cant wait for the LUA entities, I may actually be able to learn some scripting.

I'm currently planning it and working on it a lot, and I guess that it will be a worthwhile replacement for the existing DeathMatch code.

I've been wondering, whats happening with the spherical harmonic lighting?

Ah, well, while I still keep CaSHL compiling properly, I'm not really maintaing it anymore, or say, I maintain it just so that in case it would be ever needed again, it would be there. However, I never actually moved the SHL rendering code into the Material System where it should be, so current Ca3DE executables are not even able to render SHL data even if it was present.
The biggest problem probably was that the cost/results ratio was pretty bad: Although it was nice to see, it was not "stunning" (maybe scientifically but less so from the expecting-next-gen-effects and eye-candy perspective), and SHL is only good for very far away light sources (light sun, moon, etc.). The performance was very low, and it was difficult to combine it with other lighting methods, although that was more a code-design problem than a technical one.

In summary, while I of course keep the SHL code alive for possible future use, it would currently take several days or even weeks of work to activate it again. SHL is highly interesting from a scientific point of view, but currently does not help with improving 3D real-time engine output significantly but at the same time needs really much resources, which is why I decided to concentrate on other issues first.

I'm very sorry that I cannot provide you with better information, but even digging up my binary archives and verifying that they still and actually work would be a lot of effort, because you would certainly be disappointed in what you see.

[scott]

ah, oh well, Its obviously more trouble than its worth.

Just a couple of questions.

How can I make a light flicker or pulse etc?

Will you incorporate pointlights that are purely dynamic and only cast stencil shadows any time soon?

When are you planning on adding collision to detail meshes?

Could you make it possible that detail meshes can receive lightmaps?

[Carsten]

Hi Scott,

How can I make a light flicker or pulse etc?

Currently, that's only possible with changes to the SDK source code, though it's pretty easy (just modulate the lights color according to time).
I'm currently working on map/entity scripting, which will make controlling lights (and many other things) a lot easier. The new scripting systems is the major upcoming change, and will be released in summer 2007.

Will you incorporate pointlights that are purely dynamic and only cast stencil shadows any time soon?

In theory (well, and practise), such lights already exist, as for example the lightsources that the Trinity bots hold. You can also add them explicitly and separately by placing PointLightSource entities into the map. Unfortunately, until the new scripting code is done, such lightsources can neither flicker nor move without changing the SDK code. Please see below at [1] for more details about this.

When are you planning on adding collision to detail meshes?

If everything goes well, this will be included with the next major release.

Could you make it possible that detail meshes can receive lightmaps?

Hmm, well, sorry, that doesn't really make sense, because lightmaps store precomputed radiosity computation that cannot be updated at runtime when the detail object mesh moves. Therefore, detail objects get a color assigned that matches the light at the spot of ground below that object.
I know though that this sometimes yields very unsatisfactory results.
Do you have a specific problem with the coloring/lighting of a mesh?


[1] Additional detail about dynamic light sources:
I just realized that there probably is a bug in the .../Games/DeathMatch/DeathMatch.fgd file that comes with the latest Ca3DE release: The entity definition for dynamic light sources is missing.

You can fix it be opening the .../Games/DeathMatch/DeathMatch.fgd file in a text editor, find section

Code: Select all

// This is the "complement" to the texture area lights.
@PointClass base(Angles) iconsprite("sprites/lightbulb.spr") = PointLight : "Point Light"
[
    opening_angle(integer) : "Opening angle [0..180]" : 180
    intensity_r(integer) : "Intensity [W/sr] red"
    intensity_g(integer) : "Intensity [W/sr] green"
    intensity_b(integer) : "Intensity [W/sr] blue"

    // Attention! This acutally does not belong here - "PointLight" and "PointLightSource" entities ARE NOT THE SAME!
    light_radius(integer) : "Dyn. light radius" : "500"
    light_color_diff(color255) : "Dyn. light diffuse color" : "0 0 0"
    light_color_spec(color255) : "Dyn. light specular color" : "0 0 0"
]

and replace it with

Code: Select all

// This is the "complement" to the texture area lights.
@PointClass base(Angles) iconsprite("sprites/lightbulb.spr") = PointLight : "Radiosity Point Light"
[
    opening_angle(integer) : "Opening angle [0..180]" : 180
    intensity_r(integer) : "Intensity [W/sr] red"
    intensity_g(integer) : "Intensity [W/sr] green"
    intensity_b(integer) : "Intensity [W/sr] blue"
]

// An entity for a dynamic light source (like Doom3 lights).
@PointClass base(Angles) iconsprite("sprites/lightbulb.spr") = PointLightSource : "Dynamic Light Source"
[
    light_radius(integer) : "Dyn. light radius" : "500"
    light_color_diff(color255) : "Dyn. light diffuse color" : "0 0 0"
    light_color_spec(color255) : "Dyn. light specular color" : "0 0 0"
]

I've just tried it, it works, and alternatively, you can send me an email and I'll send you the whole, fixed .fgd file back, or you can wait for the next release (a minor one coming soon), which will contain the fixed file, too.

Unfortunately, there are two subtleties involved here:

• Note that the names are very confusing: The "PointLight" entity is for Radiosity (lightmaps) point light sources, while the "PointLightSource" entity is for true dynamic lights (this is what you want).
• The light_radius must be pre-multiplied "by hand" by factor 25.4. That is, if you want the light to have a radius of 200 CaWE units, you must enter a number of about 5000 in the Properties dialog. So don't be afraid of big numbers here, though note that smaller numbers mean better performance.

Both of these issues can be fixed by changing the SDK code only, and I'll implement such fixed with the next major release.

[scott]

Yes carsten that fix was exactly what I was after.
As for the lightmapping meshes, I meant for static meshes that you would use for level detail. not moving stuff like characters etc

Edit

Just gave the point light sources a try and they work great