controling the direction of player shadows

[[SAS]Solid Snake]

One other thing that would be possible is to make explosions cast shadows. I specifically made the actual shadow logic separate from the DynamicShadowVolume stuff, so it's possible to cast shadows without a volume involved. Is there anything like SpawnNotify in UT2003? I was thinking I could watch for the explosion effect to be created and add a shadow caster for them and appropriate shadow projectors for visible actors? what's the "right way" to do this?

What you could do, although it would probably mean more work, is to spawn your own type of explosion emitter. The explosion emitter would detect for actors around a certain radius, the actors detected in the radius check would then have the shadow code applied to them. However the offset is that it doesn't check for any actors during the time of explosion (since it is probably only the best thing to run the radius check once).

In my game, with source lighting I actually cut up my maps into volumes. The volumes know exactly what exactly is in there space, thus, any new actors entering the space could be stored in variables (an array is probably the best thing to do) and sorted between what is a light source and what is a actor that receives a shadow.

Running through the list, each actor could then have the shadow logic applied to them.

But this would be slow and it works well in my game since it's a rather slow paced game, and the maps are always inside a building. Thus, when you enter a room, the door behind you closes and when you exit the room the door closes again. Think of it like those console games in which the doors would always close again from room to room... that might change thou.

 

[inio]

Right now in my code there are no per-frame iterations beyond each shadow (for which this is one per player in a DSV) iterating through the array of lights for the DSV it belongs to to pick which one to use (that light list is generated once as gameplay begins). This is also some overhead from the constant creation and deletion of shadows as the player moves between volumes, but that's far from per-frame.

If there's any unrealscript wizards out there: is there a better way of generating a sorted list of structs than repeatedly inserting into an array? I need to pick out the top n lights to use, and right now it's just a pile of looping through the array, picking the place to put it, Insert()ing a blank space into the array, and filling in the fields, then picking out the top n when I'm done.

 

[Dryn]

Well

I have a similar shadow tech, and though It doesn't use light actors (lightmap with cel-shading looks terrible, so its a bit more stylised) I supose the theory would follow through ok on your project:

Have an actor that causes the shadows; give this actor a score. If you made your own light this would be easy, but you could also create a struct that contained whatever data you needed per light, and a float based score on the side.

Then have an array of these actors / constructions; the array iteration method is _much_ faster than any actual iteration function (note: an 'explosion' emitter is non existant. All an 'explosion' does is call 'hurtradius' with specific values; and all 'hurtradius' does is search through the iterator RadiusActors, and though this would work, its slow for a per tick / timer basis). Have a periodtic update (once per second would do) and update the score for all data in this array based on the default score and the relative distance to the object you want a shadow on.

Have a sub-list of usable lights (static array, length 4 or something) and the master array of all lights. Simply fill the smaller array with the top contenders for the LightScore, as explained above. As for sorting, the order is irrelevant; and if you added a threshold to whatever adds a light to the sub-list, then you could simply remove any data in a non-filled array space.

ie: you have 5 high-score lights: the sub-list holds the top 5 lights, and you make 5 shadows. However, after a while only 4 lights have a significant score; thus you would only have 4 lights in the sublist, one empty space, and you hide the 5'th shadow until it becomes needed again.

Note: you could have the sub-list a dynamic length, based on the zone property; if you wanted 6 shadows per player, it would use more resources but be cool in an area with harsh lighting; but the effet could hold easily with only 1 or 2 shadows per pawn. As this is a location-specific sort of visual enhancement, it makes sense that its the mapper's choice on how to use it.

Hope that bit of theory helps; and congrats on doing this, as it looks great! (and keep it map-specific, as Devestation uses this sort of shadowing for everything, and at times its 1337, at others its a waste of cpu power. Ntm some areas should have 5+ shadows, others shouldn't even get anything).

 

[BlackHornet]

I work on such an effect too.

Here you can see my result after one day

http://mirror.centauri-dev.net/movies/shadow.avi

The moment it only supports ONE shadow, but the mapper dosent need to place any new volume or such things......

Only a specific light, where he have to toggle a bool var on.

In case, there is no specific light in the scripted radius, i search for a Sunlight which orients the shadow....otherwise if everything failed i will use the normal UT2003 standart shadow.

PS: multiple shadows i will create, but the moment i have to do other things for the mod i worked on

 

[inio]

First, for all you mappers hoping to use this in a Make Something Unreal entry: When officially released there will be a license attached to this code that required acknowledgment in the readme. The code, unless specifically altered to not do so, will put up a small credit line in the messages during the post-game victory dance.

Back to what really matters: I have the light prioritization code working nicely for multiple shadows. It's a bit of a CPU hit if you have ridiculous numbers of lights in a small space (see below) but still within reason. I don't have the actual shadow creation happening for the additional shadows yet, but that's easy in comparison.

Specifics of cpu impact: I made a test map that was a 1024x1024 room, half of which was filled with a DSV. Covering the ceiling of the room inside the DSV (though they didn't have to be there) were 233 shadow casters with even distribution. I loaded up the map, "ghost"ed outside the room and faced away. I then ran "slomo .1" to try to slow down the bot's movements to more accurately simulate the movement through a real map's locus of lights (as that effects the sorting code). I then "stat fps" and added three bots, watching the average fps but just before the bots entered the volume (they were all headed for their own rocket launcher). the average was around 600 fps before they entered the zone, and around 300 fps once inside. Note that with a more realistic load this would not be as noticeable. The system used was a P4 2.3Ghz, with a Radeon 9600 (though the video card has no effect in this test).

A couple things about this test:
1. a frame rate of 80 would have only dropped to 70 with the same cpu impact.
2. typical maps will have lights spaced much farther than even the spacing of about 200 WU grid simulated by slomo .1.
3. If you map only has a few dozen shadow casters you could probably get away with making one big DynamicShadowVolume that encompasses the entire map.

 

[Mychaeel]

I realize this is sorta atypical as drop-in modules go,

Actually... as somebody having coded several "drop-in components" and mapping tools myself, I'm a tad disappointed by your trying to gain financial profit from this.

Granted, it's your decision, provided Epic's UT2003 license does not prohibit making money from work based on the normal retail version of the game (as opposed to an engine license) unless you're winning something yourself in the contest.

Hmm... how are you going to reward those who provided valuable feedback?

 

[inio]

Actually... as somebody having coded several "drop-in components" and mapping tools myself, I'm a tad disappointed by your trying to gain financial profit from this.

Granted, it's your decision, provided Epic's UT2003 license does not prohibit making money from work based on the normal retail version of the game (as opposed to an engine license) unless you're winning something yourself in the contest.

True, but define the difference between me and a member of a team that worked on a map? And my code relies on provided Epic content no more than even a map with entirely custom meshes textures etc does, so if they're getting money for the map I should be able to get money for the code.

Hmm... how are you going to reward those who provided valuable feedback?

discounts of coruse! One bar of latinum off for every constructive comment.

What's that you said about my ears?!?!?!

 

[Mychaeel]

True, but define the difference between me and a member of a team that worked on a map?

I'm just wondering where that leaves other people who create add-on components for the community. We have been blissfully uncommercial until now.

Should I add something similar to the license of MeshMaker (for the "Tactical Ops:Assault on Terror" team who used MeshMaker in maps for their retail release after getting my permission; or for the slim chance that there'll be another mapping contest for Unreal Tournament)? Should El Muerte do the same for UnCodeX?

For that matter, should we start charging people who win something in the contest for using the content and/or the infrastructure of the entire Unreal Wiki?

And my code relies on provided Epic content no more than even a map with entirely custom meshes textures etc does, so if they're getting money for the map I should be able to get money for the code.

But they're winning the contest. It's not like you're coding this specifically for one or another map.

At the end of the day it's Epic's call, not ours, and no amount of speculation on our part will change that; so I'm willing to drop the legal discussion without going deeper into it.

 

[inio]

We have been blissfully uncommercial until now.

Hmm... then why did I just register WOTgreal? And why are there all these people working on mods, maps, and everything else Unreal in the hopes of making a buck...

Should I add something similar to the license of MeshMaker (for the "Tactical Ops:Assault on Terror" team who used MeshMaker in maps for their retail release after getting my permission; or for the slim chance that there'll be another mapping contest for Unreal Tournament)? Should El Muerte do the same for UnCodeX?

The difference is that MeshMaker is used in the process of creating the map, where as LiveShadows (tentative title) becomes part of the map. And is distributed with it. That makes enforcing this sort of royalty setup much easier. If you can come up with a payment model for your tool that makes money without alienating users I wholeheartedly support that.

For that matter, should we start charging people who win something in the contest for using the content and/or the infrastructure of the entire Unreal Wiki?

Again, the issue of enforcing the payment model becomes a sticking point. What about having certain "premium" content with a limited number of page-views per account per day, unless you upgrade your account to Pro (costing $3-$5)?

But they're winning the contest. It's not like you're coding this specifically for one or another map.

But they chose to include my code in their map. Sourced player shadows will hardly make or break a map, but they could make a slight difference in how it's received.

At the end of the day it's Epic's call, not ours, and no amount of speculation on our part will change that; so I'm willing to drop the legal discussion without going deeper into it.

Do you have someone at Epic I could contact about this? As for dropping it, that sounds good until release time comes.

 

[Radiosity]

and everything else Unreal in the hopes of making a buck...

I'd just like to point out that I mod this game (skinning, modelling, some coding, animating, you name it I do it) because I enjoy it. Money makes no difference to me whatsoever. If someone wanted to use something I'd created in a commertial venture of some nature I'd simply be pleased that they thought my work good enough to want to use it. Obviously as long as they a) ask my permission to use it, and b) give me some credit for using it, then that's all that matters. As soon as money comes into it, then I've stopped modding for enjoyment and might as well just give up and do something else.

 

[Dryn]

Hmm... I think if any commercial element explicitly used my work, I would ask for some $ in return. After all, such appliations is where the $ is. However, I think you're asking to be ripped off by having that bit about the prize there; though its a neat system you have, its certainly not impossible to create an equivalent, even using completely different logic. (heck, I already had a method, one guy here has a post of something similar, the whole game of devestation used tech like this, etc). Thus though that sounds fair in one light, I would have to say pre-emtively stating something like that is onlly going to bite you in the ass later; either people generate thier own equivalent, or avoid yours. Not that on paper it doesn't sound fair, but as soon as you start capitalising a free service you will find out why the dot-coms suddenly fell appart.

(If you had, say, a specialised version of ued which offered not only these shadows but a whole whack of nice little extras, and designed as no-brainer for the mapping community, then it may be fair asking for $ should any such map win. Otherwise, though this is neat, I feel its too small to cause the map to win, and thus shouldn't be rewarded monitarily for its use. Not that you shouldn't get credit though, and if any mapper does win using some 3d part code addition, it would be in his or her best interest to reward that code-author with a portion of the prize money. However, this should be the choice of the mapper, or perhaps a rule in the make-something-unreal contest, not a harsh deffinition before the code is released)

 

[Mychaeel]

The difference is that MeshMaker is used in the process of creating the map, where as LiveShadows (tentative title) becomes part of the map.

Does that discount the work I put into developing, implementing, testing and releasing MeshMaker?

You are making a very strange and arbitrary distinction here between "something that is used in the process of making a map" and "something that is used in the process of playing a map" as if that made any difference in the worth of the visible results or its involvement in the creation process.

And is distributed with it. That makes enforcing this sort of royalty setup much easier. If you can come up with a payment model for your tool that makes money without alienating users I wholeheartedly support that.

I am not talking about legal tricks or PR management here. I am seeing a questionable precedent here that I disapprove of because I am sure it will have a detrimental effect on the Unreal modding community if it becomes widely adopted. The latter is also why I never even thought about inventing any "payment scheme" for anything I released within this community.

Again, the issue of enforcing the payment model becomes a sticking point. What about having certain "premium" content with a limited number of page-views per account per day, unless you upgrade your account to Pro (costing $3-$5)?

Do you see now how ridiculous that whole idea sounds? It's a community project, not something to commercially exploit.

either people generate thier own equivalent, or avoid yours.

That is true. There is very little in your component that you can make legal claims on, should somebody decide to produce their own solution for the same problem and distribute it in a similar fashion as you mean to.

 

[inio]

There is very little in your component that you can make legal claims on.

You are not in a position to evaluate that. I have copyright on the source code itself. If someone else produces a competing product, it's their burden to prove that every algorithm they use is not a derivitive of my work. My code has several original algorithms and techniques not used by the Epic code or mentioned by anyone here, and to produce a competitive product you would need similar functionality. Proving that you didn't derive that functionality from my product would be very hard.

I feel its too small to cause the map to win

I agree, but would you say that this might improve a map's chances by 1%? By setting the "price point" where I did, I effectively am making mapers ask themselves that: "do sourced shadows improve my map by 1%?". For me the answer would probably be yes.

 

[[SAS]Solid Snake]

Hmm... then why did I just register WOTgreal? And why are there all these people working on mods, maps, and everything else Unreal in the hopes of making a buck...

It is up to you to register for WOTgreal. I and many others can code fine without the use of a UScript program. In fact I use Notepad.exe ... which I suppose I paid for when I paid for my copy of Windows.

The mods that were out before the competition sought a couple of things, one possibility was to have experience in the game making field and to use as a resume, another is to make a game which can go commercial (Tac:Ops / DoD), another is to have fun, another ... there are so many reasons.

You are not in a position to evaluate that. I have copyright on the source code itself. If someone else produces a competing product, it's their burden to prove that every algorithm they use is not a derivitive of my work. My code has several original algorithms and techniques not used by the Epic code or mentioned by anyone here, and to produce a competitive product you would need similar functionality. Proving that you didn't derive that functionality from my product would be very hard.

You are right that it would be hard for someone to prove that their code didn't derive from yours, but can you prove that their code is derived from yours? You can't since they will deny and you will insist or the other way around. For example, I already made sourced directional shadows a long time ago as many others had. Once I had done the basic algorithum I dropped it and picked up some other stuff I wanted to do. Since I made source lighting before you, can I even try to say that you derived my code? No, I can't nor would I even begin to try, as it's impossible. None the less, I think I will probably stick to my own methods now & find out how to darkness/FOV on my own as I probably don't want to get stuck in legal stuff between myself and I. Although I have looked at your code, I could only credit my code myself in that I didn't use your code as a base, and that I worked it out on my own ... oh well ... more work in the barrel.

IMHO, I think this is why some community efforts turn stale [This could be why some great games/mods fall apart]. Tanus, which made some great code, especially his mouse code which is what powers the entire mouse code in my own mod, hasn't asked for anything but creditation(To my knowledge).

 

[inio]

It is up to you to register for WOTgreal. I and many others can code fine without the use of a UScript program. In fact I use Notepad.exe ... which I suppose I paid for when I paid for my copy of Windows.

This was in response to Mychaeels' claims that "We have been blissfully uncommercial until now."

As for copyright on code, I can prove that I have never downloaded any maps or mods that included directional lighting, as I have not yet loaded any maps or mods for UT2003 (other than the bonus packs). Also, the portions I will be enforcing my copyright on are the prioritization and selection code for multiple simultaneous shadows, and the transitioning mechanism for switching between shadows (whether it be multiple or single).

 

[Dryn]

But there's the rub

On this scale, there is very little you can do to prove ownership of code. If its blatently copied, its kinda obvious, and I frown on _anyone_ doing so. However, its not as if this is unique; its certainly slick, and a neat idea tying it to a volume, but shadows like those you have made are not absolutely tied to your own work. Thus, what can you offer per way of proof that you haven't looked at the devestaion dynamic shadows (I know you haven't, but the point still holds)? Those aren't necessarily UT related, but that is an example of algorithms that produce the same result with absolutely no relation to your own code.

I appreciate what you have made, and think that any 3rd party mapper tool is a boon to the community. However, to add a price tag to a specific chunk of code useable in maps, if only for something like a prize, is distasteful, in the least. You do deserve credit if such is used, but thats about the end of it; any $ as a part should come from the respect of the mapper who used this, and not from a declaritive statement pre-completion.

Also, for copyright: in my computing lectures / labs you will be damned for copying if you have something which explicitly matchs the code of another classmate. However, how can you possibly have 50 students doing the same assignment, many getting 90%+, and yet none be actually copying? As mentioned above, before the talk of money, I gave the theory for a system of handling shadows: it works, it looks great, and its relatively fast. How does that theory match yours? I have no clue code wise, though externally I would say they do about the same thing...

Don't get me wrong, you've made a nice little project. But thats it, end of story. Its a neat revision of a dynamic that is NOT unique to yourself (Hell, I had this working 3 months ago, tied to different light actors but easily portable. Though its been used elsewhere, I can offer my own efforts as proof to this statement.) As such, its a good thing for the community that you created this tool, and any mapper who uses it should in turn give you credit. If in the odd chance that such a mapper wins a prize, I would consider it honorable to give you a share of the said prize, or at least some official mention (but such decided by the mapper and the mapper only, not a pre-emtive statement). Thats the full extent of it: in programming, esspecially surface level programming such as uscript, you need to create something extremely valuable in order to recieve $ from it. This is possible, and you should take every opportunity to recieve such $, but unless you have something that changes the way we look and think about gaming, I frankly don't want to pay for it. (ESSPECIALLY if something similar has been done before, done elsewhere, and will be done again, regardless of your personal efforts.)

P.S. I Think that any software used by a commercial development team, or even semi-commercial, should be liscensed for $ though. Should I create a really potent editing tool, and its used quite a bit in Unreal 3 or some damn thing, I would certainly like a little bit of $ for my efforts, though a tiny amount compared to liscensing max or photoshop.

 

[Mychaeel]

This was in response to Mychaeels' claims that "We have been blissfully uncommercial until now."

I won't let a single instance of an entirely optional convenience utility count as a valid argument against that statement.

There is an overwhelming number of sophisticated add-on or "drop-in" components which are distributed entirely without any commercial interests attached, in the spirit of what I always thought was the foundation of a community like this: the fun of doing it, learning from it, and possibly getting favorably known for it.

As I said a few postings before, I'm mostly just disappointed. On some level I feel cheated for the sympathy and support I was willing to give you; that might have been different, had you made your intentions clear to start with. Plus, I feel that you are implicitly discounting all other community-created tools and developments that are published in the spirit of what I described before by specifically charging for your component as if it was something entirely out of the usual.

As for copyright on code, I can prove that I have never downloaded any maps or mods that included directional lighting, as I have not yet loaded any maps or mods for UT2003 (other than the bonus packs).

I doubt that. (Not that you haven't done it; that you can prove it. Or that it matters.)

Also, the portions I will be enforcing my copyright on are the prioritization and selection code for multiple simultaneous shadows, and the transitioning mechanism for switching between shadows (whether it be multiple or single).

I frankly doubt that there are many different possible ways to reasonably do that to start with.

As Dryn states, blatantly copying your code would be something that's obviously wrong on many levels, but if somebody thinks hard enough on their own and comes up with something very similar to your algorithm, you have no case at all (unless, for the mere sake of the argument, you had patented your algorithm which in turn would mean that you would have to prove first that nobody else ever did anything similar before; which, given the narrow scope of the problem, seems rather unlikely).

It's not very uncommon for coders to have the feeling they have invented the wheel after having implemented something cool; but it's hardly ever actually the case when you look at it from a distance.

For the sake of your community reputation, maybe you should reconsider this part of your licensing scheme.

 

[Mychaeel]

Hmm. I knew your name rang a bell. You were the guy who, more than a year ago, went through great lengths to "protect" a map-embedded script that displayed and then faded out a logo on startup.

http://forums.beyondunreal.com/showthread.php?t=103769

 

[inio]

Well, what would you rather have: that I don't release the module at all, or that I release it with the 1% clause? Maybe I should let the Mapping forum decide, since they're who it really effects.

 

[EvilDrWong]

Well, what would you rather have: that I don't release the module at all, or that I release it with the 1% clause?

i know this is generally frowned upon in any forum other than the Off Topic section... but...

No offense, but what youve done isnt the great gift that you think it is. As a few people have said before they did it and it musnt be that hard, because there is more than one who has. Threatening us with the lack of such a feature isnt exactly the kind of thing to sway peoples opinion about it. It can be done, and for less than the 1% clause.