Christmas in Spring
Moderator: Moderators
Ok, now for brass tacks, though: what exactly would the workflow be, to:
A. Add a normal-mapping shader.
B. Have it invoked through LUA.
C. Have it applied to a model.
D. Exclude from cards that do not support shaders.
i.e., I'd love to be able to use normal maps, but I have zero idea how to get from A to D here.
Moreover, I can see that this makes all sorts of interesting stuff possible, but I guess I'm really having trouble seeing how we're going to apply it to models or FX scripts, which is where the action's at, in terms of making anything more interesting than a map with "weather". Not that that isn't really kewl. But when we can add this to units, then we're really cooking with gas. I can already see it- metallic shaders with iridescent colors applied via a bitmap, animated textures, procedural warping stuff... all of the kewl things shaders can do, liberated into Spring. Just need to cross the line and go from applying it to the GUI elements to S3O meshes without causing 'orrible things to happen. Of all of the things you've done, Trepan, this could in the longer term be one of the biggies- it could totally transform the graphical capabilities of Spring- IF we can apply it to "working objects"- the bitmaps used by maps, the geometry used by mesh models, etc.
Tell ya what: I will be more than happy to make a nifty normalmap and detailed walkthrough for a NB unit for display and testing purposes, if you will help us get past square one here. Because this could be a really gigantic big deal. Like about half of this stuff in the next release... only even I am smart enough to see that I won't have to bury myself in LUA code to mess with this, if the path from shader ---> model/texture data ---> renderer is made clear.
Oh, and while I'm musing about this... can we use it to FINALLY read the blue channel of our S3Os and do whatever we want with them, like I proposed we should be able to do, oh, about a year ago? That would be IDEAL, because we're already loading that texture, we have a full 256-color channel available, and if we have some way of saying what shader to apply, then we're golden, because we can apply that shader with only very modest performance hits beyond whatever resources the shader eats while running. Just askin'.
Can't go to C, you have to call the unit draw through Lua. Would be pretty fast if you used a drawlist for the mesh, a vertex shader for the animation and some skeletal animation format to feed the animation in there.Make a Lua parser for md5mesh and md5anim and do that. You can disable the unit drawing with some Lua call beforehand. Then you have the one-two combo of custom shaders AND skeletal animation that can just be exported from some animation program.
Oh and please release it under a less restrictive license than GPL, otherwise I'll be forced to reimplement it just to let mods choose any license they please (e.g. Smoth couldn't use GPL code since he wants to maintain creative control over his mod).
Oh and please release it under a less restrictive license than GPL, otherwise I'll be forced to reimplement it just to let mods choose any license they please (e.g. Smoth couldn't use GPL code since he wants to maintain creative control over his mod).
If we can't go to C, and we don't have code to import another model format <imagines trying to get MD5 animations to have anything like the flexibility of BOS, and shudders with horror at the amount of animations you'd need to build, let alone call through a fairly slow interface> then this is not really useful yet.
However, I see no real practical reason why it cannot read the drawlist directly from the drawlist created by the S3O, and use that blue channel in bitmap 2, or an arbitrary range of bitmaps specified by a user within custom LUA rules.
And, just for the record, Smoth is in no position to defend copyrights to anything but ancillary stuff like BOS scripts in his project anyhow, so I really think that's a moot point. It's not like he could sue for use of his models, when they're clearly in violation of Bandai's copyrights in the first place. So that's kind've a red herring, imo.
However, I see no real practical reason why it cannot read the drawlist directly from the drawlist created by the S3O, and use that blue channel in bitmap 2, or an arbitrary range of bitmaps specified by a user within custom LUA rules.
And, just for the record, Smoth is in no position to defend copyrights to anything but ancillary stuff like BOS scripts in his project anyhow, so I really think that's a moot point. It's not like he could sue for use of his models, when they're clearly in violation of Bandai's copyrights in the first place. So that's kind've a red herring, imo.
Smoth isn't going to sue anyway since that's a waste of money for something like this but he doesn't want people to take Gundam and make "extreme Gundam" or drop the units into other mods, if he used GPL stuff he'd be forced to allow that, no? Also personally I reject the idea of "take it but these are the strings attached:", I wouldn't take a GPL script simply because I want to keep my options available and if I want to say "use it however you see fit" I don't want the GPL hindering me.
I don't think there's a drawlist for the complete s3o, after all you can't rotate parts of a drawlist, it would have to be one list per piece and with Lua you'd have to read their rotations and render them in the right places.
Also I don't know what you're trying to do but it has to be something insane if you say using normal keyframe animation is too limited. You realize you can mix animations and have controller bones that can be turned to make the unit aim, etc?
I don't think there's a drawlist for the complete s3o, after all you can't rotate parts of a drawlist, it would have to be one list per piece and with Lua you'd have to read their rotations and render them in the right places.
Also I don't know what you're trying to do but it has to be something insane if you say using normal keyframe animation is too limited. You realize you can mix animations and have controller bones that can be turned to make the unit aim, etc?
Er, last time I checked, you don't want to use real-time blending in a RTS, that's far too wasteful. That's why in games like DOW, the characters don't actually aim at the targets- they just turn until they're centered, then run an animation. Real-time mesh deformation via IK is strictly for a FPS or something where you can afford to use that much CPU manipulating the verts and doing interpolation calculations.You realize you can mix animations and have controller bones that can be turned to make the unit aim, etc?
Anyhow, this is all completely irrelevant. If I can't hook into my existing content base, which represents many man-months of people's free time at this point, then I'm not using this.
IK? Who was talking about IK? You realize that adding some rotation to the spine bones won't take much processing power (at least not any more than turning a piece)? DoW's units do aim at their targets, you could've tried the WIP Tau mod where aiming wasn't implemented yet, all units shot into the wrong direction.
Also who's talking about using the CPU? I said GLSL shader, that runs completely on the GPU.
Also who's talking about using the CPU? I said GLSL shader, that runs completely on the GPU.
<shrugs> look, I'm not trying to argue here. I thought you meant IK, because you're talking about MD5, which is an IK format, to my knowledge, used in FPS games which use interpolated poses. But that's as much as I actually know about that topic, frankly- I've never modeled any characters for a FPS before, and all my experience with IK systems is from working in Poser, which is probably completely different anyhow.
I'm just saying that if this doesn't work with S3O, I am not using it, because we have too much time invested in S3O content, our pipeline is about delivering it and getting it integrated into Spring... and I'm not at all interested in porting it.
If there's an easy, straightforward, documented and flexible path to using, for example, the blue values of Texture2 in a S3O to apply shaders to a model, then that's a powerful and flexible tool in my toolkit, using technology I already know, like, and understand how to use, and "all" I have to do is find an appropriate GLSL shader, or write one, and then implement it into the game I'm working on. Not an impossible task, for somebody in the middle of a huge project.
If it requires a completely new workflow, requires that I spend a lot of time staring at LUA code that I already lack enough time to deal with, and requires that I port models to a format I don't even know anything about, then I'm simply not interested at this time, k?
I understand that you're excited about this for different reasons than I am, and by all means, do whatever you think is kewl. I'm sure there are bazillions of things that can be done with this, most of which I'm too dense to imagine. But all I'm interested in, frankly, is three things:
1. Alpha transparency, FINALLY.
2. Bumpmaps. Simple, grayscale, good ol' fashioned I've been using them for a decade bumpmaps, or full-blown normalmapping... I don't care, honestly. For the scale and polycount we're dealing with, the faster that shader runs, the better- I don't want to build Oblivion, I just want some extra highlighting and surface detail without adding tricount that will count every rendering pass.
3. Surface shaders for specific color / lighting FX, such as a reflective shader that gives me control over top-end and low-end RGB values for specular and shaded areas, for better simulation of metallic surfaces.
Relatively "simple" stuff, really- just a year or two behind the bleeding-edge stuff of last year's games. It'd make a world of difference to the final feel of my game, though.
I'd love to see a Kernel Panic version, for example, that used animated textures, scripts to generate a call to a shader during COB events (for example, I'm sure that zwxwg's current nifty tricks could be better-done through LUA than through COB, but I digress)... or other stuff. That's great, and I'm all for it.
But, at the same time, I can't use that stuff, either- I have way too much else on my hands right now, and a pause to mess with this is just not in the works for at least another month or so, while the major content issues are being dealt with...
I'm just saying that if this doesn't work with S3O, I am not using it, because we have too much time invested in S3O content, our pipeline is about delivering it and getting it integrated into Spring... and I'm not at all interested in porting it.
If there's an easy, straightforward, documented and flexible path to using, for example, the blue values of Texture2 in a S3O to apply shaders to a model, then that's a powerful and flexible tool in my toolkit, using technology I already know, like, and understand how to use, and "all" I have to do is find an appropriate GLSL shader, or write one, and then implement it into the game I'm working on. Not an impossible task, for somebody in the middle of a huge project.
If it requires a completely new workflow, requires that I spend a lot of time staring at LUA code that I already lack enough time to deal with, and requires that I port models to a format I don't even know anything about, then I'm simply not interested at this time, k?
I understand that you're excited about this for different reasons than I am, and by all means, do whatever you think is kewl. I'm sure there are bazillions of things that can be done with this, most of which I'm too dense to imagine. But all I'm interested in, frankly, is three things:
1. Alpha transparency, FINALLY.
2. Bumpmaps. Simple, grayscale, good ol' fashioned I've been using them for a decade bumpmaps, or full-blown normalmapping... I don't care, honestly. For the scale and polycount we're dealing with, the faster that shader runs, the better- I don't want to build Oblivion, I just want some extra highlighting and surface detail without adding tricount that will count every rendering pass.
3. Surface shaders for specific color / lighting FX, such as a reflective shader that gives me control over top-end and low-end RGB values for specular and shaded areas, for better simulation of metallic surfaces.
Relatively "simple" stuff, really- just a year or two behind the bleeding-edge stuff of last year's games. It'd make a world of difference to the final feel of my game, though.
I'd love to see a Kernel Panic version, for example, that used animated textures, scripts to generate a call to a shader during COB events (for example, I'm sure that zwxwg's current nifty tricks could be better-done through LUA than through COB, but I digress)... or other stuff. That's great, and I'm all for it.
But, at the same time, I can't use that stuff, either- I have way too much else on my hands right now, and a pause to mess with this is just not in the works for at least another month or so, while the major content issues are being dealt with...
There is no such thing as an IK format for games. Doom 3 has IK for the feet but e.g. Quake 4 doesn't use that FootIK stuff. Aiming is FK anyway. Though I think the walkanims for those spidermechs the elite TA scripters made would qualify as IK.
Greyscale bumpmaps aren't used these days anymore (at least internally), it's less complicated (for the hardware) to use a dot3 bumpmap AKA normalmap since a heightmap would have to be converted to normal offsets at rendertime anyway so why not store the normal offsets in the texture and get more flexibility for free? AFAIK the Doom 3 engine converts heightmaps into dot3 bumpmaps at loadtime.
Greyscale bumpmaps aren't used these days anymore (at least internally), it's less complicated (for the hardware) to use a dot3 bumpmap AKA normalmap since a heightmap would have to be converted to normal offsets at rendertime anyway so why not store the normal offsets in the texture and get more flexibility for free? AFAIK the Doom 3 engine converts heightmaps into dot3 bumpmaps at loadtime.
After looking at the warp effect, would it be possible to add a LUA script that uses the warp center as a toggleable Zoom effect?
Say a smaller area over the cursor that acts like a magnifying glass?
For instance if you're zoomed out far in game, and want to look closer at a specific area without taking your eyes off the whole picture.
Yes there is a minimap for this, but would still be neat.
Say a smaller area over the cursor that acts like a magnifying glass?
For instance if you're zoomed out far in game, and want to look closer at a specific area without taking your eyes off the whole picture.
Yes there is a minimap for this, but would still be neat.
Topic Res Anyway, I was wondering, in the next version of spring will all this stuff be available? Will I be able to add rain into the tree map? Seeing as I have to wait for the next version anyway, I thought I should see if rain in it was possible aswell. (Then I can do a rain and a sunny version, WOOT)
aGorm
::::Edit:::: ALSO, cause I have no idea how to add LUA stuff to a map, would anyone be able to fill me in on it?
Support for lua shaders has been in SVN for a while now.
Here's a package I made for ya:
http://trepan.bzflag.bz/spring/zip/LuaGaia-rain-000.zip
It contains the gadgetHandler source code, and two gadgets.
The Gadgets/precipitation.lua is the one that will interest you
(the cmd_doline.lua gadget is useful for dev'ing lua gadgets).
http://trepan.bzflag.bz/spring/lua/precipitation.lua
Unzip the package into your map, repackage the map, and try
the following commands (as the host player):
.luagaia help
.luagaia help rain
.luagaia rain 0
.luagaia rain 1
.luagaia rain speed -100
.luagaia rain speed 250
.luagaia rain scale 500
.luagaia rain scale 5000
.luagaia rain density 10000
.luagaia rain density 100000
.luagaia rain texture bitmaps/arm1.gif
.luagaia rain texture bitmaps/circularthingy.tga
Once you've got the settings you want, edit the variable
settings at the top of the Gadgets/precipitation.lua file.
P.S. If you plan on adding your own texture, I'd suggest
placing it in LuaGaia/Images/yourtexname.png
Here's a package I made for ya:
http://trepan.bzflag.bz/spring/zip/LuaGaia-rain-000.zip
It contains the gadgetHandler source code, and two gadgets.
The Gadgets/precipitation.lua is the one that will interest you
(the cmd_doline.lua gadget is useful for dev'ing lua gadgets).
http://trepan.bzflag.bz/spring/lua/precipitation.lua
Unzip the package into your map, repackage the map, and try
the following commands (as the host player):
.luagaia help
.luagaia help rain
.luagaia rain 0
.luagaia rain 1
.luagaia rain speed -100
.luagaia rain speed 250
.luagaia rain scale 500
.luagaia rain scale 5000
.luagaia rain density 10000
.luagaia rain density 100000
.luagaia rain texture bitmaps/arm1.gif
.luagaia rain texture bitmaps/circularthingy.tga
Once you've got the settings you want, edit the variable
settings at the top of the Gadgets/precipitation.lua file.
P.S. If you plan on adding your own texture, I'd suggest
placing it in LuaGaia/Images/yourtexname.png
Cool, and just to check, all that in the map zip? Its basicly like having another folder like 0bjects3d and textures, ect.... and special LAU folder. Wicked!
Now if only I wernt going on holiday tommorow, and my computer was not in teh middle of a compleat re build I copuld try it out and post a screeny...
so you'll all have to wait a week.
aGorm
Now if only I wernt going on holiday tommorow, and my computer was not in teh middle of a compleat re build I copuld try it out and post a screeny...
so you'll all have to wait a week.aGorm
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
