Interesting Shadows

[skwasjer]

The light node has been supported by S3D for over a year (since jan 2008 in fact). There was confusion over the last float value (not just by me but by many others) but I've found the first float is Attenuation and the second is range and obviously only applies to Omni lights. (I;ve posted this in my online changelog of the WIP-build). Omni lights need a range, because they don't cast light infinitely like ambient/directional. The reason it's called 'unknown' still in current public build is that I only recently did some tests and analyzed the SH4 shaders... Before that I assumed it was another color value, which it wasn't, so I changed it to unknown so I could look into it at a later date.

Btw, omni lights are used throughout the interiors and have a label 'Omni_1', etc... Not too hard to figure out that a value of -2- is a point light.

Of course, you wouldn't need to figure this out if you would at least give S3D a go just once... you might even be able to contribute to it (like others have, ie. Anvart, ref, privateer, sergbuto and other old skool hex users)... I don't care if you are not interested in it for production work, just reuse the knowledge. It's there for everyone to see.

[TheDarkWraith]

thanks for the info It made sense that 0 was Ambient, 1 was Directional but wasn't sure about the 2 as I've never seen that value used before (but then again I never poked my head into the sub interior files either).
So, just to clarify, for the omni lights that last float value is actually the atten factor and not the intensity like for ambient and directional?

[skwasjer]

The first float (intensity) becomes attenuation (gradual loss of intensity), and the 2nd float (the last 4 bytes) is 'Range' in game units. In the ambient/directional scenario this has no meaning and no data is stored at all... (in this case the chunk is 4 bytes shorter)

[edit]
Here's the structure:

public class Light
{
LightType _type;
Color _color; // ABGR
float _attenuation;
float _range; // Not stored when _type != 2 (Omni);

.. excluded property accessors..
}

public enum LightType
{
Ambient,
Direct,
Omni
}

[TheDarkWraith]

Originally Posted by skwasjer

The first float (intensity) becomes attenuation (gradual loss of intensity), and the 2nd float (the last 4 bytes) is 'Range' in game units. In the ambient/directional scenario this has no meaning and no data is stored at all... (in this case the chunk is 4 bytes shorter)

thanks for that

[Nisgeis]

Originally Posted by Racerboy

If you know the files and the file structure and aren't afraid of the hex editor then yes. Using S3D - not sure (since I don't use S3D I'm not a good source of information on this). I bet it doesn't understand some of the nodes used.

If you don't use S3D, then you should, it will increase your productivity. With S3D you don't need to waste any time finding out what a particular value is, as it is read and indexed for you and displayed in a readily available format. S3D is very well worth a download. It is to hex editting, what the word processor was to the typewriter.

EDIT: Rattyness removed.

[TheDarkWraith]

harbor update: not looking good so far. The problem is still trying to get objects to cast shadows onto other objects without all the waviness due to water interaction. I can get objects to cast shadows onto themselves but it really messes up the harbor as you can see the shadows of another object through the one you're viewing plus the latter problem. The ultimate root problem is this:

with the subs, ships, guns, etc. you define a light source and place it at the tree root. Take for instance the VIIb sub. The light source is attached right at the VIIb's root node (which has parent ID of 0x0) which is NSS_Uboat7b. Now everything that is attached to this receives 'shadow' light. All you have to do to have objects attached to it to cast shadows is attach DynamicShadowCast controllers to those objects. Now the harbor doesn't want to play. I place the light source at the tree root (using Brest currently so it's Brest_harbor_Dummy) and no shadows (nowhere, not even on the objects themselves). I create a base node off of Brest_harbor_Dummy and attach the light source there - same thing. I add a 'shadow' light source to each individual object (in the harbor kit file) and now they cast shadows on themselves but the aforementioned problem above occurs.
I've even tried stripping away the StaticObject controller to no avail.
Since the harbor objects are clones I created a real lighthouse in the harbor to see if I could get shadows from it or have it cast shadows on itself. Same problem. If I give this lighthouse it's own lightsource it will cast shadows onto itself with beginning aforementioned problems.

[Graf Paper]

Break time from spring cleaning so I thought I'd pop in and see what's what.

So it looks like I was near to the mark about that value being some sort of diffusion for point lights to limit their range to a defined sphere. Thanks for that info to confirm an educated guess on my part, skwas.

I figured the u-boat interior lights, harbor buildings' exterior lights, and other similar such lighting were type 2. It's just that star shells were the best example that came to mind first because they dramatically illustrate the effect of omni-directional light.

I just wonder how the type 1 directional light of searchlights is attenuated (assuming it's not some weird implementation of type 2 light).

Regardless of how anyone prefers to work, it is their free choice to use whatever tools they feel comfortable with. Racerboy obviously likes the more fine-grained control that hexing allows him to have.

I also would not say his remarks were to be taken as disparaging S3D or skwas' methods when designing S3D. Rather, I think it is borne more out of a desire not to "prejudice" his own discoveries by tainting his ideas about what the data signifies. Thus his commentary of my information gleaned through S3D was more disclaimer than refutation.

Of course, I may be wrong but let's give anyone the benefit of the doubt because we've all been misunderstood a time or two in our lives. Simple text on a screen compounds this exponentially.

I do not possess the olympian hex and assembler skills of either Racerboy or skwas. As a mere mortal, I am content to use the tools made by those who know better and trust in their judgement as it is honed by years of working with this code.

I especially love the model viewer that has so well illustrated how the environmental lighting is actually a bounded sphere that defines a source by using the x,y,z coordinates in relation to the sphere surface.

Translation (rotation) of the sunlight is still pure withcraft to me. Does it have something to do with an orthogonal projection to determine the angle of incidence when striking a surface?

Yet again I thank you, skwas, for giving me the tool I needed that allows me to contribute to our marvelous community!


In regards to the harbor...

I know from observation that land does not actually exist, per se. It seems that land is defined more as a two-dimensional plane that "floats" in the water. Yes, even the sea floor is done this way as you can actually look under it and see..more water! I believe the SH3 "world" is actually a hollow sphere of water with a value of 500 meters depth or thickness. Perhaps the harbor shadows are somehow being rooted in the "real" foundation of the harbor, which is the water that is in turn the root node everything else rests upon.

This is all conjecture on my part, based upon observations when the camera did strange things, like falling through the ocean floor or finding its way under solid land to reveal that the land was a hollow shell. I hope this might spark some ideas.

I hope that perhaps you and skwas can work together on this and find an answer, RB!

Break time is over. Mrs. Paper is calling me back to work.

[TheDarkWraith]

Originally Posted by Graf Paper

I just wonder how the type 1 directional light of searchlights is attenuated (assuming it's not some weird implementation of type 2 light).

wpn_Searchlight.wpn_Searchlight Render Controller...beam....Visual beam object.

Visual beam object is usually the type:

SearchLightEffect...SH3 SearchLightEffect Render Controller. Works only on water surface....Angle...Cone angle, in degrees..Light color.Light range (meters)....Atenuation..Light intensity = 1 / (A + B*<distance>)....A...A factor....B...B factor....HaloSize....Halo size (fraction from camera X size).....0....7...7...7......(9.."9...9...\Search LightEffect.cpp

look in \data\Library\Search_Lights.dat to see examples.

[skwasjer]

Originally Posted by Graf Paper

I just wonder how the type 1 directional light of searchlights is attenuated (assuming it's not some weird implementation of type 2 light).

It's not. The directional light type is a light that is cast in one direction. The amount of light on all areas is equal and does not 'fall off', it's also not a cone shape, and is not related to the position of the source or the width of a beam. This is commonly used for ie. the sun (as it's so far away). Basically, only the rotation (orientation), intensity and color are meaningfull here. This type of light should as such not be confused with 'spot lights' that are cone shaped and fall off/diffuse the farther you get away from them.

Lights like a search light are implemented differently. They use a special controller, a cone shaped model or a model with several intersected flat planes (depends on what effect you want), with semi-transparent texture (fall off is done using alpha channel and controller settings), and special shader that brightens up the spot when you look directly into it. I don't remember the actual implementation from the top of my head but I don't recall it using a 'light node 4/2' either.

[TheDarkWraith]

Which one looks most realistic:
#1


or #2


#1 is shadows using only Sunlight as the light source. Notice how the gun shadow appears on the side of the hull (wrong). From where the sun was there was no way this could happen in real life because the deck of the VIIb would be blocking that shadow from reaching the side of the hull. Also the gun shadow appears on the deck and stops before ever going 'over the side' which further proves my point.

#2 is shadows from Sunlight light source mixed with shadows from ambient light source.

This effect was only done to the VIIb's hull. I figured out a way to mix shadows without corrupting them. This could possibly be used to mix in an omni-directional light (since it has fall-off) to model light attenuation the deeper you go under water. Now whether we can add an omni light and whether it will work underwater is the next question...

[tonschk]

I my opinion both screenshots have a couple of shadows mistakes , the number one screenshot looks a bit better but the gun have two shadows and the conning tower dont cast Dynamic shadows on itself

[emaluzer]

If an enemy ship spots your sub or a lighthouse light hits your sub are there shadows?

[TheDarkWraith]

Originally Posted by emaluzer

If an enemy ship spots your sub or a lighthouse light hits your sub are there shadows?

that is an interesting question! I have not looked into it. I will do some testing and find out

[LordNeuro"Serbia"]

Is there any shadows of athers ships on the water and them self. If a harbor shadows dont work i think we cann live with ships and sub shadows. After all 90 % of time u r at see. Keep doing wery good job RB. I hope there is going too bee same relise soon on thise subject , theat u cann use in a carer mod.

[TheDarkWraith]

Originally Posted by LordNeuro"Serbia"

Is there any shadows of athers ships on the water and them self. If a harbor shadows dont work i think we cann live with ships and sub shadows. After all 90 % of time u r at see. Keep doing wery good job RB. I hope there is going too bee same relise soon on thise subject , theat u cann use in a carer mod.

if you use the v1.0 SH3Controllers.ACT and follow what FlakMonkey posted then the ships that are already correctly setup will cast shadows. There are quite a few stock units that will cast shadows.