P.O.P.S.- Demo 3.1 available!

[manolo_]

my configs

amd 3000+
ati 9700 mobile
1,5 gb ram
wind xp sp2

(low water, no shadows)

so its an old system, the demos doesnt crashed or something, but i didnt recognized any difference compared to older demo u released for the self-shadowing (or something like that)

[Argh]

Did you turn LuaShaders on, in SpringSettings?

[1v0ry_k1ng]

cool idea, It worked although there was a large black square on the screen (some kind of de-bug?)

this would work better with more blue-ish, less foggy fog and less and more sporadic bubbles (of varing sizes)
and possibly some fish

[Argh]

Yeah, the black box is just a diagnostic.

This isn't really meant to be a complete implementation of "under the sea", just a demonstration of the many uses of the particle system's general capabilities.

OK, working on fire systems now. Did some reading, and I'll see how I can put together something reasonably-interesting.

[manolo_]

Did you turn LuaShaders on, in SpringSettings?

yes

[Master-Athmos]

Both for you modfile itself as for a modfile with the updated Lua files I just get an extremely foggy scene with the known (and working) normalmapped balls (using a HD4870). Infolog gives me errors in your POPS shaders:

[ 0] GLSL Light Shader Succeeded
[ 0] Loaded gadget: GLSL Lighting <glsl_lighting.lua>
[ 0] Loaded gadget: DualFog <gui_dualfog_gadget.lua>
[ 0] Loaded gadget: 00000Visible Units (Gadget Version) <000000visibleunitsgadget.lua>
[ 0] POPS Vertex Shader Failed
[ 0] Vertex shader failed to compile with the following errors:
ERROR: 0:73: error(#160) Cannot convert from 'const float' to '3-component vector of float'
ERROR: error(#273) 1 compilation errors. No code generated

[ 0] Loaded gadget: Bubble POPS <pops2_bubbly.lua>
[ 0] [unit_normalmap_shader:Initialize] shader1 compilation failed
[ 0] Fragment shader failed to compile with the following errors:
ERROR: 0:57: error(#160) Cannot convert from '4-component vector of float' to '3-component vector of float'
ERROR: 0:107: error(#202) No matching overloaded function found mix
ERROR: 0:107: error(#160) Cannot convert from 'const float' to '3-component vector of float'
ERROR: error(#273) 3 compilation errors. No code generated

[ 0] Loaded gadget: unit_normalmap_shader_tst.lua <unit_normalmap_shader_gadget_sur.lua>

[Tribulex]

Retested, it all works great, but your sounds are obnoxious :)

Also the debug stuff is annoying. Take that out of releases maybe? or at least explain what it does.

[AF]

Argh, refer to the failing gracefully thread in the AI forums, then apply it to your own work.

I leave you with the following piece of code

Code: Select all

if(luashaders == true){
run P.O.P.S code
} else{
display little box saying you need to turn lua shaders on, and remove P.O.P.S stuff from the active environment
}

Responsible coding that validates is not hard, failing to make such simple failsafe checks means buggy code and instability, and worst of all ignorance.

[Argh]

First section of Initialize():

Code: Select all

  if not gl.CreateShader or
      not gl.CreateFBO() then
    Spring.Echo('POPS will not run with your hardware')
    gadgetHandler:RemoveGadget()
    return 
  end

The GLSL errors are also doing exactly what they're supposed to do: they report GLSL failure, and then exit gracefully. I need error strings from ATi users, in order to diagnose any compilation failures, so I wrote it to work that way.

[AF]

Console spam at the start of the game means those kinds fo things normally get lose in a flurry of text messages.

[Argh]

Also the debug stuff is annoying. Take that out of releases maybe? or at least explain what it does.

What it does is to display one of the FBOs as a it updates- it's a very practical demonstration of what's happening in the application.

I can't emphasize this enough:

I sorta expect you programmers to sit down with the code and start building particle effects on your own with this, once I get the basics of management done, which is the last major goal.

The final code in P.U.R.E. will probably be much more specialized and therefore a lot harder to understand the derivations (a lot of the specific optimizations involve GLSL changes to remove math steps and other things to improve efficiency) so, instead of building, say, a fire sim, and then seeing several fire sim knockoffs later, because most people don't know how the general model was built, I wanted to give people the general case now, so that you can solve for anything you can imagine (and figure out an algorithmic approach to).

This is why it's so important to get the general case debugged for all hardware now, so that it's nice and clean and people who find GLSL and the heavy-duty OpenGL stuff really scary never have to mess with that, just the basic logic that drives particle creation, which is Lua (and very easy to work with, it's basically just parameters, if that's all you work with).

Basically, this program works in the following fashion:

1. You give it parameters for creating a new agent. That part will be a lot more clear and commented fully in the next release, when I (finally) hook up synced with unsynced, after doing some testing to determine what the fastest way to go about certain things will be. But basically, the objective for the synced code is to create something that, if not totally foolproof, is at least something that can feed a "black box" of OpenGL and logical operations, for people who don't ever want to look at the guts and make it do really specific stuff (or optimize it).

2. The agent's 32-bit and 8-bit pixel values are stored in textures that are created at runtime, using Frame Buffer Objects (FBOs) to pass a result from GLSL shaders. For those of you for whom 'FBO' is just an acronym, FBO just stores the current frame buffer result- OpenGL uses many frame buffer results from each operation, layer by layer, to give you a final result that looks like a picture. We're just catching an immediate part of this giant process to use in a special way. FBO is really easy to use, and goes hand-in-hand with shaders.

3. Further FBOs then read the pixel values stored, and modify them over time, again using GLSL to perform most of the math on the GPU.

4. The final shader pass then takes the modified textures and positions the point objects in world space. Because the updates in step 3 happen very rapidly, this creates the illusion of motion, like pretty much anything in 3D graphics.


Looking at the specific shaders, what happens to those pixel values, and therefore to our particles, is determined by the GLSL's logic- it does practically all of the heavy lifting:

1. The quad shader is provided the initial values of the motion simulation and writes them to the correct pixel, for physics later.

2. The color quad shader writes color values that are stored in 8-bit textures for retrieval in the final steps. We use 8-bit because their smaller size and already-clamped values are ideal for simple color values (or texture values, or etc.).

3. The physics shader alters 2 textures, based on the values of the 4 used to store all of the data necessary to create a simple simulation of motion, using very simple equations. Obviously, this is one area where optimization / deviation from the general model is possible- remove un-necessary physics steps, add special steps to do something new, etc.

4. The LOS shader alters one texture's pixel values, black or white, depending on Lua-supplied game logic. It updates infrequently, because CPU use is a consideration (basically, the bigger the map, the longer it takes to return- a performance tweak to allow faster updates on smaller maps might be a good idea, maybe I'll get to that).

5. The final shader positions the vertexes in world space, gets certain data to allow for LOS retrieval by determining where the particle is, and then passes to the fragment shader, which is, in the general model, set up to do colormap emulation, where it cycles through color values delivered via texturemaps, and then blends that with a main texturemap to arrive at final RGBA values and write the texels to the frame buffer, where it then is interpreted according to blending instructions in the OpenGL portion of the loop- a very important part of its final look and feel.

Anyhow, I'll try and find the time to clean it all up a bit and comment it better, once I know that it all compiles on ATi. It is really a very simple program that uses a lot of GLSL as "subroutines" of a sort, though.


@AF: I'll look at a cute box about LuaShaders, but tbh it seems pointless. They're on by default in Spring installs (and certainly are configured that way in P.U.R.E. installs), and if an end-user has turned them off, they've done so manually, and I assume they have a good reason- they have an Intel 945, for example. The best thing to do there is to fail gracefully and depart with as little fuss as possible, and write a FAQ entry that says,

Q. Where are those nifty effects I see in screenshots?

A. If you have an Intel graphics chipset (i.e., you're trying to play this on a typical netbook), ATi card older than a Radeon 9800 or GeForce older than 6800, Wolfe Games regrets to inform you that your hardware can't run the effects, so we've shut them off to prevent the game from crashing. If you have a new graphics card from ATi or nVidia, please contact Wolfe Games and they will help troubleshoot the problem.

Kloot actually addressed the crashing part recently, but it never hurts to explain to end-users why something is missing, imo- frequently, people don't read specs for games. I don't have time to write an OpenGL 1.x spec fallback for that segment of the market atm, and they would be very unhappy with the performance anyhow, so it's better that it's not there than makes for a miserable experience.

[MidKnight]

Both for you modfile itself as for a modfile with the updated Lua files I just get an extremely foggy scene with the known (and working) normalmapped balls (using a HD4870). Infolog gives me errors in your POPS shaders:

Same card, same problems.

[Argh]

Working on a fix. Please "stay tuned", it is more than likely I will have to write more than one set of fixes, and I can only do this with the help of you ATi users

[Argh]

OK, I finally got done with a set of fixes, basically just tried to nail down anything that wasn't totally explicit (probably went overboard, tbh).

Let's see if this sucker compiles on ATi. Here's version number two of the bubbles. Sorry nVidia guys, nothing new in this one, I'm still working on fire / smoke / management.

If it fails to compile, please send me error reports.

[manolo_]

i tested it - nothing new. is my gpu to old?

[Master-Athmos]

Still not working:

Code: Select all

[      0] GLSL Light Shader Succeeded
[      0] Loaded gadget:  GLSL Lighting       <glsl_lighting.lua>
[      0] Loaded gadget:  DualFog             <gui_dualfog_gadget.lua>
[      0] Loaded gadget:  00000Visible Units (Gadget Version)  <000000visibleunitsgadget.lua>
[      0] POPS Successfully Compiled
[      0] Loaded gadget:  Bubble POPS         <pops2_bubbly.lua>
[      0] [unit_normalmap_shader:Initialize] shader1 compilation failed
[      0] Fragment shader failed to compile with the following errors:
ERROR: 0:57: '=' :  cannot convert from '4-component vector of float' to '3-component vector of float'
ERROR: 0:107: 'mix' : no matching overloaded function found 
ERROR: 0:107: 'assign' :  cannot convert from 'const float' to '3-component vector of float'
ERROR:  compilation errors.  No code generated.
[      0] Loaded gadget:  unit_normalmap_shader_tst.lua  <unit_normalmap_shader_gadget_sur.lua>
[      0] Loading LuaGaia

@manolo:
Maybe Argh went for a SM3 model for his shaders which your card simply wouldn't support. The particle system itself current won't run on your ATI card anyway but if you already have no fog around I guess Spring "skips" the shaders that don't work (check your infolog)...

[Argh]

Hrmm, says that POPS compiled. You sure you don't see bubbles, Athmos? You have to zoom in to the ground, I made them pretty subtle in this version, I was doing some experiments with blending modes. Looks like I managed to break the normalmap shader on ATi, though, I'll get that fixed up again.

@manolo_: The Radeon 9700 supposedly is GLSL compliant (i.e., this should work). How long has it been since you updated your drivers?

Ok, here is version 3. Should address the goofs in the normalmap shader.

[Master-Athmos]

Ok - error reports are fixed now (sphere center seems to be offset now though) but I still don't see any bubbles. It looks like this:



(EDIT: LuaShaders are on of course.)

[Argh]

Hmm, odd. Maybe it doesn't like the blending mode. I'll take a look at that.

[Argh]

OK, here's using a different blending mode, let's see if this helps. Meanwhile, I'll get back to working on fire / smoke.