Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Dragon on July 15, 2009, 04:50:03 pm
-
Is that possible to add such features?
I would like to see, for example, yellow lighting on fighter when it passes through hole in GTI Arcadia.
Or blue when it goes through engine wash of a terran capship.
It would also be great to have glowmaps, thrusters and glowpoints reflect in glass and other reflective surfaces, like now does environment.
-
Is that possible to add such features?
I would like to see, for example, yellow lightning on fighter when it passes through hole in GTI Arcadia.
Or blue when it goes through engine wash of a terran capship.
It would also be great to have glowmaps, thrusters and glowpoints reflect in glass and other reflective surfaces, like now does environment.
:yes:
-
I would rate shadows more important, but heck, this would be cool as well.
I'm just curious about how the amount of light sources affects the amount of render passes and their speed...
-
Do you have the slightest idea how incredibly difficult and system-intensive those requests are? Emissive light from textures on a per-pixel basis? Real-time reflection? MAJOR game studios, like Epic and iD, are only JUST starting to implement things like this.
Sorry to rain on your parade, but it ain't gonna happen.
-
I don't see why we couldn't use engines as a point light source, though. It wouldn't really be any different than it is for weapons, and would provide for some cool effects when fighters traverse capships. :)
-
Unfortunately Galemp is right.
As for engines, however, I like the idea, and it sounds a bit more feasible than some of the other points. One small problem is the range of stuff affected by the engines... particularly, there should be 'shadows' cast on the ship itself (i.e. even if a point is very close to the engine and facing the right way, if part of the ship model is between them, it shouldn't be illuminated.
This could possibly be achieved using some sort of baked lightmap, but it would have to be separate from the -glow maps, and able to adjust to match the throttle/afterburner/normal pulsing behavior of the engines. But then there might be trouble with the combination of multiple independent engine glows. It could probably be done, though, and a lot more easily than some of the other suggestions you made.
As for reflecting certain things off of shiny stuff, that would be particularly difficult given the way the rendering engine is structured. It's really too old and bloated, unfortunately--that sort of change would require more of an overhaul than a tweak, if I'm not mistaken. The thing is, in order to do it, you'd need to basically draw the scene a second time for each time stuff is reflected.
Also... one small problem here is that you're saying 'lightning' and that's confusing me. I'm here thinking you're talking about lightning (i.e. big bright zig-zaggy branching plasma thingy that happens during thunder storms), when what you mean is l-i-g-h-t-i-n-g. I'm sorry if I sound like a jerk saying that, but if it messes with communication, it stands in the way of doing anything.
-
baked lightmap
mmm chocolate...
I'm going to second what Aardwolf and Galemp have said. The engine just isn't up to that kind of abuse at present. I'm not sure how it's done with weapons though (I have noticed that when stuff goes bang you get some lighting effects)
-
As for engines, however, I like the idea, and it sounds a bit more feasible than some of the other points. One small problem is the range of stuff affected by the engines... particularly, there should be 'shadows' cast on the ship itself (i.e. even if a point is very close to the engine and facing the right way, if part of the ship model is between them, it shouldn't be illuminated.
An easy workaround is just to not have the engines light the ship they're mounted on. They would only cast point lights (the same as weapons fire uses) on other ships. That, IMO, should be relatively easy to implement.
-
Yeah, I think at the very least that if the engines emit light, the effect for the ship they're mounted on would have to be done differently than for other objects nearby.
-
id implement this through the existing glowpoints pof chunck. you could make a type 2 glowpoint, its radius being its effective area. if 2 lightning points have intersecting radius and are both on at the same time then lightning can arc between them. the bitmap for the glowpoint could be used in the effect. it could be bindable to rotating subobjects as well for added effect.
you could use the games existing nebula lightning and ship sparks type rendering.
but of course the poster of this thread cant spell lighting
-
I'm sorry, I posted this around midnight in my time, I relied mostly on spellchecker when writing this.
BTW, what are glowpoint types?
I know that type "0" is the regular glowpoint, but what are other types for?
-
id implement this through the existing glowpoints pof chunck. you could make a type 2 glowpoint, its radius being its effective area. if 2 lightning points have intersecting radius and are both on at the same time then lightning can arc between them. the bitmap for the glowpoint could be used in the effect. it could be bindable to rotating subobjects as well for added effect.
you could use the games existing nebula lightning and ship sparks type rendering.
but of course the poster of this thread cant spell lighting
Yeah, he wasn't talking about 'zap' lightning. But that is still an interesting idea (although your implementation plan sounds too hack-y).
-
the glowpoint chunk just seems to have been made with future expansion in mind. making them emit lightning is a plausable expansion.
I'm sorry, I posted this around midnight in my time, I relied mostly on spellchecker when writing this.
BTW, what are glowpoint types?
I know that type "0" is the regular glowpoint, but what are other types for?
well bunnies, its 6:30 am i havent slept in over 36 hours and i just made my lua based table parser work flawlessly :D
anyway there are type 0 which are glows and 1 which are beams. if there are more im unaware of them.
-
What, is there an int (i.e. 32+ bit value) associated with each glowpoint?
-
No, Bobboau just coded in two types, 0 and 1, depending on whether they're camera-oriented or space-oriented.
-
it might be parsed internally as bool, but if bob followed the existing scheme more likely theyre enumerations. but anyway the point is if two types were added, why not more? in addition to glow points why not lightning points and particle spewers and the like. i even thought about sound effects points. or killzones.
the glowpoint chunk is a good place to put anything that needs a position, normal, and radius, since it also has a properties section and a type int?, that makes the glowpoint system a pretty good foundation for other model-level effects. the other advantage is that most converters allow you to import glowpoints directly from the ship model when you convert it. its sertainly better than creating new pof specs.
-
... did somebody say something about baked lightmaps?
You know that crappy tilemapped ships look a lot better with baked lightmaps, don't you? ;)
I condsider this to be one of the most important visual features right now. More important than real-time reflection, or engine lights.
-
Wait, what?
/me can't tell if that was sarcasm or not, what with this being the Internet
Assuming you're SRS, tho... what feature are you saying is the most important, exactly? Do you mean baked lightmaps with separate uvcoords, or what?
-
Just look at the high poly Iceni. See how the engines make the surrounding area glow blue? That.
-
So, he was serious, but it's an already existing feature... What about the tilemaps bit?
-
Sarcasm? :nervous:
-
So, he was serious, but it's an already existing feature... What about the tilemaps bit?
A second UV channel. Get that working and you could upgrade *any* tile mapped ship using a baked lightmap texture in the second slot. Where it would really shine is with BIG ships. eg Tiled mapped with Ambient occlusion.
-
Ah... I had interpreted it as sarcasm, but it made me think about the possibility of using a second UV channel anyway. Only problem being you beat me to the punch. :D
-
It could also work with landscapes.
-
Yes, we could instantly create pretty nice lanscapes if we could bake lightmaps. And pretty big ones too.
Wait, what?
/me can't tell if that was sarcasm or not, what with this being the Internet
Assuming you're SRS, tho... what feature are you saying is the most important, exactly? Do you mean baked lightmaps with separate uvcoords, or what?
Yes, that's what I ment...
The thing is, without a material system, it's probably not going to happen. :(
I wouldn't mind getting this feature without a proper material system though. We could start doing amzing thing with it now, which could be easily modified to work with a real material system later, once it's done.
-
Is there any work being done on a materials system?
Is it even a definite step on the roadmap?
Are there plans for how it would work when we finally get to that step?
And what would it do exactly, anyway?
I was thinking, in some ways it might be better to just overhaul the in-game rendering code, get it working for the bare minimum case (i.e. so that FS2 retail runs properly), and see what else it broke, adjusting stuff as it is found. Possibly a code branch.
But I can't confidently say that that doing so would really get the improvements faster rather than slower.
-
a second uv channel would open the door to many more cool features than just baked glowmaps. its something id like, a lot. question is how. something needs to happen at the pof level, add a second set of uv coords to each vertex in each polygon, requiring the object chunk to be upgraded. or you can stick it in another chunck all together, but that seems like a hack. youd also have to update all the convrters to handel it.
-
If you're going to UV the ship, you can turn the tile mapped version into the UV mapped version just by putting the tiling on the new whole map. Then bake lightmaps away.
-
It's a matter of texture space. Having two separate sets of uv-coordinates per vertex would mean you could get the per-area detail provided by the tilemap in parts that are tiled, without having redundant stuff in the texture. Of course, it would depend on the modeler making competent use of the feature.
-
I didn't think having redundant stuff in the texture mattered. And having two maps instead of one takes up more memory and is less efficient then. There's simply no reason for tile mapping that can't be better done with a good UV these days.
-
If you're going to UV the ship, you can turn the tile mapped version into the UV mapped version just by putting the tiling on the new whole map. Then bake lightmaps away.
Oh no!
That would require a lot of way too big textures.
Remeber the huge asteroid in BtRL? While it looked like it was tile mapped, it wasn't.
It used a lot of 2048² textures. Still, on close-ups, it looked as sharp as a wall in Half-Life 1, when you got close to it.
You can't bake a lightmap on tile mapped ships unless you use a lot of gigantic textures. It's a waste of memory.
The textures need the sharpness (which they get from being tile mapped), while the lightmaps do not need a lot of texture res. One 1024²-2048² should be enough for all bigger ships.
That means 4-5 small tile maps and one 2048² map, opposed to the system without lightmap, which needs ten 2048² maps, to get a decent texture res.
To bake a light map, everything needs to be mapped unique(!) The light is different on each part of the ship.
On a symetric ship, you can bake it for one side though and mirror it on the other half.
-
Hmm, I hadn't thought about using a smaller map in the second UV channel. Guess that could help.
-
Hmm, I hadn't thought about using a smaller map in the second UV channel. Guess that could help.
I hate being inarticulate. :(
-
Hmm, I hadn't thought about using a smaller map in the second UV channel. Guess that could help.
I hate being inarticulate. :(
It's ok, it happens to the worst of us.
-
If you consider lighting also be aware that right now only the first gun of each bank is a light source. If a ship has two guns in one bank, each on one side of the fighter, that is VERY obvious (think of an xwing for example). So adding light sources at least to the first TWO guns per bank would help to make things a little more symmetrical.
-
For cycling firepoints we'd need every firepoint to be a light source. Otherwise you'd only get a flash 1/4 of the time on the X-wing for instance.
-
Are you talking about light-emitting muzzle-flashes, or the actual light source that moves along with the shots?
With either, if push came to shove, I imagine you could try to average the positions of the shots, and in the latter case, if one shot dies before the others (e.g. when it hits something that they manage to clear), the average would be recomputed.
I figured this was how it already worked, but it seems there are several discrepancies I was previously unaware of.
-
it would also fix a slew of normal mapping issues. you would be able to uv map the diffuse texture to make much better use of pixel space, then youd have max or whatever moddeling program you use rearange your polygons on the uv map, then move the polyons around to squeeze more space out. you just create your normal maps with that chanel.
another idea i can think of, rtt decal (i like to call it scorch) mapping. every time your hull gets hit, draw a mark to it, whether it be a bullet hole or a massive burn. other mod ideas would use it for things like reentry glow, it would be applied to polygons in a particular direction and added to the glow map. would be awesome.
-
Almost like something I'd considered for use in my own programming... basically, using the actual ship's vertices to avoid z-fighting, and picking the proper uv coords to make the texture show up in the right position. Except it sounds like you're talking about actually doing a sort of real-time bake-to-texture. If you could save on drawing passes that way without sacrificing much quality, then it seems like a good idea.
-
Just look at the high poly Iceni. See how the engines make the surrounding area glow blue? That.
He's talking about baked lightmaps like a new addition to the engine on top of the other features. The Iceni uses a glowmap for that.
-
Are you talking about light-emitting muzzle-flashes, or the actual light source that moves along with the shots?
With either, if push came to shove, I imagine you could try to average the positions of the shots, and in the latter case, if one shot dies before the others (e.g. when it hits something that they manage to clear), the average would be recomputed.
I figured this was how it already worked, but it seems there are several discrepancies I was previously unaware of.
I was talkling about the light source that moves along with the shot. Saga implements different shaders that make gun lights even more visible and there it is extremely obvious when fighters have far apart firing points. I don't know about the muzzle flashes but I guess that's probably the same.
And as stated above, especially for fighters like the X-Wing this is extremely obvious and needs to be expanded.
-
Almost like something I'd considered for use in my own programming... basically, using the actual ship's vertices to avoid z-fighting, and picking the proper uv coords to make the texture show up in the right position. Except it sounds like you're talking about actually doing a sort of real-time bake-to-texture. If you could save on drawing passes that way without sacrificing much quality, then it seems like a good idea.
for decals its not likely that you would have to draw to the texture every frame, or on the same frame that the collisions occure. im not sure if it would be more efficient to draw stuff as a batch or each as it happens. you might want to schedule the scorch map updates, if many occur at once, over several frames.
im still toying around with rtt in scripting. while it works ok with panels and stuff of that nature, mainly because of the lower resolution used (usually less than 512, i find 256^2 adequate for panels and hud elements). there are exceptions, like if you call renderFrame() to a couple dynamic textures every frame. im sure that with the increased resolution of larger textures that performance will be impacted. the question is how much.
-
Nuke: I've noticed during profiling that textures are swapped a hell of a lot - I'm pretty sure that we could achieve a large performance boost by avoiding that, but I'm not a graphics coder so I'm not sure how to go about that.
-
what do you mean by profiling? i know that reducing the movement of data back and fourth between the video card is a good way to kill performance. im not sure how much of the render to texture capability is handled at the gpu level, or if at all. i do know that most video hardware is capable of doing rtt quickly and effectively and has been for some time. i remember seeing video monitors in games as far back as quake 3 (and even further back if you count older games that used software, glide or d3d). im very intrested in optimizing rtt in scripting.
one thing i tried is time slicing rtt operations, things like camera linked cockpit video displays get updated less frequently, every other frame or every third frame (depending on how many of them there were), and skipping a frame when updating the radar texture. though it didnt seem to work well, and in some cases actually degraded performance. in the future i might only allow one video display and even then skip frames with it. all the real fixes i can think of are at c level, such as adding render options to renderFrame(). for example, make it so i can disable things like normal maps and specular when i call it.
anyway i intend to report a slew of scripting bugs once the new cockpit demo rolls out (mainly because it uses many features which demonstrate the bugs). most of them deal with things not working right in an rtt context, or at all. scripting is a good way to minimize feature creep in the engine, however it seems to need some optimization in some areas. some of the new features in the cockpit demo will make it possible for scripters to write scripts which can be handed to modders who have little or no scripting knowledge, and then be used to add features which are not directly part of the engine.
-
VS Team Editions can analyze code performance in real time, and profile it, to analyze it for bottlenecks. Things like timing what functions are eating the most cpu time, etc.
-
i just have the express edition, so im not sure i have that feature.
the render targets system to me is just some magic thing that makes rtt work, i have no clue how it works internally, or how to script it efficiently. things like this make me wish i had a better understanding of opengl. i think it might be possible to perform render to texture with a shader run on the video card. the textures would never need to leave video memory, only procedures for drawing stuff need be passed, which usually use very small textures. stuff like hud elements for example.
-
You don't then, not even Pro does :P
-
But express doesn't have plugin support.
-
Very Sleepy is a free tool for basic profiling:
http://www.codersnotes.com/sleepy/
Works pretty well. Create a DEBUG build, throw it and the .pdb file into the Freespace directory, start it up, start up Very Sleepy, attach to process, and you're set. Pretty easy & straightforward.
-
it works, but i havent a clue hat t look for.