Shadow Calculator

[oger-lord]

Hi,
as promised I am working on the shadow calculator.

Current Features:
-Uses all cores
-Has a progressbar
-Supports alpha tile (alpha tiles do not cast or receive shadows)
-Debug Window, displays loaded terrain and doodads

I tested it with a complex map (Heart of the darkest Night) and it took 10 minutes to calculate the shadows.
The algorithm is simply bruteforce with the ray collision algorithm of the jmonkey engine.

I still need to fix some bugs with ramps and special doodads.
Do you have suggestions for other features?

 

[PurgeandFire]

Could you allow the person to specify a particular region and only calculate the shadows within that area? (append onto the current shd) e.g. they would specify a (minX, minY) to (maxX, maxY).

 

[Zwiebelchen]

You have been working on this secretly? You magnificent bastard!


Finally we have a powerful toolset for editing and calculating shadows fast, especially when combined with WaterKnight's SHD merger.

How does the alpha tile thing work? Does it ask for a tile to ignore? I'm using a multitile with an alpha component for saving texture space, hence I only need one variation of a tile invisible, not all.

Anyways, here are my suggestions:
Let the user define areas to ignore for the calculation. This is useful when you have interior areas in your map. Obviously, in a dark cave, you shouldn't have any shadows from sunlight.
Basicly the same as Purge's suggestion. Depends on what implementation you prefer.

How are the results? Does it compare to a shadowmap calculated via the editor itself (minus the bugs, obviously on large objects)?

 

[Ezekiel12]

Seeing this is written in Java you might consider adding it here if it takes off, with the goal of having as much as possible modding functionality in one place.

 

[oger-lord]

Could you allow the person to specify a particular region and only calculate the shadows within that area?

Yes, that could be useful with large maps and a slow computer.

How does the alpha tile thing work? Does it ask for a tile to ignore? I'm using a multitile with an alpha component for saving texture space, hence I only need one variation of a tile invisible, not all.

Ah, okay, I didnt think of that. But it should be possible to implement. At the moment it checks weather the complete blp is transparent.

Let the user define areas to ignore for the calculation. This is useful when you have interior areas in your map. Obviously, in a dark cave, you shouldn't have any shadows from sunlight.
Basicly the same as Purge's suggestion. Depends on what implementation you prefer.

How do you want to define the areas? As regions in the editor with something like "ignoreShadow" in the name?

How are the results? Does it compare to a shadowmap calculated via the editor itself (minus the bugs, obviously on large objects)?

I think its okay, I could make an image with the shadows of a map once calculated with the editor and than with the tool so you can see the difference.

 

[Zwiebelchen]

Tbh, I wouldn't even care if it looks different, as long as it still looks natural.

But yes, defining areas to exclude via regions with a specific naming convention would be a simple and effective approach.

 

[Zwiebelchen]

So, any news on this? To say it with the words of Freddy Mercury:
"I want it now."

 

[oger-lord]

I implemented the regions that are ignored.
Now my problem is that the w3e specification concerning the texture details for a tile is incomplete:

1byte: texture details (of the tile of which the tilepoint is the bottom left corner) (rocks, holes, bones,...). It appears that only a part of this byte is used for details. It needs more investigations

And I need this informations for the alpha tile check. I already found out that the last 5 bits gives you the same id the editor shows when you place terrain variations manually.
After I fixed this I could send you an alpha version for testing.
I mean Gaias does not have cliffs, so you would not have the problem with the ramps.

 

[Zwiebelchen]

I implemented the regions that are ignored.
Now my problem is that the w3e specification concerning the texture details for a tile is incomplete:

And I need this informations for the alpha tile check. I already found out that the last 5 bits gives you the same id the editor shows when you place terrain variations manually.

I don't have knowledge about that either, unfortunately. But why even care about the alpha tile when you always have the option to simply draw a region on top of it?

After I fixed this I could send you an alpha version for testing.
I mean Gaias does not have cliffs, so you would not have the problem with the ramps.

... actually it does have some cliffs and ramps - mostly to overcome the limits of terrain height modification.

 

[oger-lord]

Okay, it seems like the first 3 bits have something todo with the cliff variations.
However I am not able to see how these data fit together with the cliff variations that are displayed.

Good news: The changes made to detect the alpha tile are now working.

 

[Zwiebelchen]

I just wanted to post to commence the hypetrain on this.

Oger-lord just sent me a preview version of his shadow calculator to test and the results are amazing. Absolutely comparable to the default shadow calculating of WC3 (if not better), but at only a tiny fraction of the time required (and 64bit support).

 

[Bribe]

Please let us know when a public version is ready! Some questions:

- Does this interact with World Editor?
- If not World Editor, does it just hack into the .w3x file and run the shadow calculations?

 

[Zwiebelchen]

So, any updates on this with the fixed alpha tile shadows?

@Bribe: nope, it's a simple external tool; you just select a map to calculate shadows for and it will do the calculation and show a preview window.

 

[Bribe]

That's awesome, so I can buid the map on my slow laptop but then calculate the shadows on my quad core PC that won't let me install NewGen

 

[Dr Super Good]

The first 5 bits of detail are the terrain tile variation. These run from 0 to 31 but actually only 0 to 17 are used because an extended tileset only has 18 variations (2 core, 16 from extended area).

The last 3 bits of the byte are for cliff variation. From what I have seen there are 4 different values of this which come in the form of flags. Each cliff variation comes from more than 1 vertex due to cliffs being produced between vertexes.

World editor defaults cliff type to 15 and variation bits to 0 for vertexes which never have had cliffs. It never clears these fields once set even if the vertex is no longer part of a cliff. As a result you can get some bleeding over of map construction details from this. The cliff detail also acts as a pointless source of random noise which will decrease compression efficiency slightly.

 

[Zwiebelchen]

Any progress? I think this is hot iron...

 

[oger-lord]

I fixed the problem with the ramps and I started to add the border for the alpha tile.
Right now I am unmotivated because there are tons of special conditions that turns the code slowly into a mess.

The last 3 bits of the byte are for cliff variation. From what I have seen there are 4 different values of this which come in the form of flags. Each cliff variation comes from more than 1 vertex due to cliffs being produced between vertexes.

But you did not figure out the formula? I am still confused, in the end there are not more than 3 different cliff models as a variation and sometimes only 2.

 

[Zwiebelchen]

I fixed the problem with the ramps and I started to add the border for the alpha tile.
Right now I am unmotivated because there are tons of special conditions that turns the code slowly into a mess.

Does it really matter if the code is messy? If it works, it works... Optimization hardly matters when it's a compiler you only run in special occasions anyway. I'm fine waiting a few minutes longer.

 

[oger-lord]

Does it really matter if the code is messy?

Yep, because it means the code is hard to read and understand and it does not make much fun to extend it even further.
Maybe I need to complete it and later I can try to rewrite it.
Especially with the terrain you need to try out many things and it is hard to directly make the right decisions.

 

[Zwiebelchen]

Yep, because it means the code is hard to read and understand and it does not make much fun to extend it even further.
Maybe I need to complete it and later I can try to rewrite it.
Especially with the terrain you need to try out many things and it is hard to directly make the right decisions.

But you are already in the ballpark. The preview version you sent me was almost perfect already, with some minor stuff. I wonder what it is that makes this so much more complicated?

 

[Dr Super Good]

But you did not figure out the formula?

They appear to be variation flags. For a total of 4 variations as each flag appears mutually exclusive. Each cliff is comprised of multiple vertexes since a cliff needs at least 4 to present an area. A simple pillar of Cliff is 9 vertexes in total. Hence how so much variation can be achieved.

 

[Zwiebelchen]

So, any chance we can get an official release on this soon?

I can workaround on the water issue by just replacing the tile at these places just fine, so the additional requested features aren't that important, really...

 

[Zwiebelchen]

Sorry to bug you with this, but this tool is super cool... it would be a shame if you wouldn't finish it or make it public...

No pressure, but...

 

[oger-lord]

Give me two month to finish my bachelor thesis.

 

[Zwiebelchen]

Give me two month to finish my bachelor thesis.

That's cool. Good luck with your thesis!

 

[pyf]

bump

Hello oger-lord

any news ?


I see your http://www.hiveworkshop.com/forums/lab-715/warcraft-3-hq-263682/ thread is closed. I hope the project is not abandoned. I use your animated trees 0.2 to embellish my WC3.

With the release of patch 1.27a (now using D3D9), some comments on that thread might not be relevant anymore.

I will probably write a tutorial to help people make your Polygon Enhancer 0.01 (or any Java program requiring OpenGL2) work on Intel i915GM graphics.

*Edit*
Done

 

[Zwiebelchen]

It's a shame he never finished this. I mean; it is so close to completion, just missing a very minor feature!

I still have the testing version he sent me. Maybe someone else is willing to finish his work on it?