Two stupid questions about CSimpleGroundFlash

[Argh]

1. Is the correct phrasing the same as a normal, old-style Groundflash, except for defining a Texture?

2. Will it respect dir?

[Argh]

Hrmm. The answer to question 1 should be "no", but the following code causes a crash:

Code: Select all

[groundflash_LIGHT_ARTY_EXPLOSION_FX01]
	{
		class=CSimpleGroundFlash;
		[properties]
		{
		Texture=circularthingy;
      		flashSize = 20;
      		flashAlpha = 0.6;
      		circleGrowth = 0;
      		circleAlpha = 0;
      		ttl = 30;
      		color = 1, 0.7, 0.3;
		}
	air=1;
     	ground=1;
      	water=0;
	count=1;
	}

... so I guess I'd better go back to the old phrasing, however, then how do I invoke it and declare Properties?

[Argh]

Hrmm, all right, here's what's in SVN:

http://spring.clan-sy.com/fisheye/brows ... dFlash.cpp

Cutting out the non-relevant stuff, these are the parameters:

CR_MEMBER(size),
CR_MEMBER(sizeGrowth),
CR_MEMBER(ttl),
CR_MEMBER(colorMap),
CR_MEMBER(texture),

... so lemme take another swing at this. Pity that we can't use rings with this, but that's a minor problem.

[Argh]

Ok... it works. Here's a simple dynamic flashbulb:

Code: Select all

[groundflash_FLASHBULB_FX01]
	{
		class=CSimpleGroundFlash;
		[properties]
		{
		texture=GroundFlash_Test;
      		size=45;
      		sizeGrowth=-1;
      		ttl=30;
      		colorMap=1.0 0.7 0.3 1.0     0.1 0.1 0.1 1.0     0 0 0 0.01;
		}
	air=1;
     	ground=1;
      	water=0;
	count=1;
	}

BUT:

1. I cannot get a black texture to draw correctly on the map. I've tried everything I could think of, including weird inversions I think colormap may not be working quite right. Anybody have a clue here? I never have a problem with dark objects drawing correctly otherwise... simply draw dark, use the alpha to declare what's drawn... maybe this isn't respecting the Alpha channel

<tested>

No, it doesn't respect the alpha channel, despite being ColorMap. Drat! I would really like that, and some method of randomizing FX, so that I can replace the GroundScar stuff forever, with something that is more flexible and more efficient. Oh well. It is great for animated sparkly, so boo-hoo, I guess I'll just have to live with it. At least now I can time it with... muahahaha... I just thought of a very cool use... I'll show it in PURE, if it works... could save a lot of particles though (that's a hint).

2. Textures need to be declared in [GroundFX], not in [Projectiles].

3. Obviously, it doesn't respect Dir, which means I can't use it for what I was hoping for (better fake light simulation). Nor can I use it to get rid of the randomized groundscars, until I figure out what's making Colormap behave so poorly.

[Argh]

WOOOOOOT. I am very, very tempted to make a movie. I have figured out a really cool trick that you can do with this code! Among other things, you can use this with other stuff to save a LOT of particles, for volume effects

However, PURE Alpha is almost ready, so I'll just wait until I make formal promo stuff. I don't have all of the CEGs that I want done anyhow. I'll just give you a screenshot for now:



Hey devs... I don't suppose I could tempt y'all into maybe writing another variant on this, that would support these things:

1. Z-order (kind've a problem with the current one, tbh, doesn't draw every time)

2. Position (obviously, x, z only- right now the only way to do that is with a DelaySpawner).

3. Dir, where unless dir is specified, it uses the standard projection angle, otherwise projection is from dir to surface, obeying relative rotations XYZ of emitting point. I don't know how this code is doing the projections, though, so skip that if it's either too expensive or too much of a pain in the butt. I would like it mainly for custom "light sources", and I suspect that implementing it game-side will be a pain, and it won't get used by many people other than me, so, er... but it'd be kewl, darnit... I swear! I see it in my head already... swinging "lights" that project distorting "sources" onto the map... gunflares with distinctive shapes... opening hatches with appropriately-shaped "light"... it's all cheating, of course, but it'd be useful fakery, imo.

[Pressure Line]

id like that light sources thing... rotataing beacons for factories and con units while they are building would look great



hawt!

[Snipawolf]

I can't get this to work, I copied your example into my file and added the stuff that need be added, but it doesn't even show up...

Code: Select all

[HumanBlood]
{
[groundflash_HBloodSplat] 
   { 
      class=CSimpleGroundFlash; 
      [properties] 
      { 
      texture=bloodsplat; 
            size=45; 
            sizeGrowth=1; 
            ttl=30; 
            colorMap=1 1 1 1   1 1 1 1   1 1 1 1; 
      } 
   air=1; 
        ground=1; 
         water=0; 
   count=1; 
   } 
}

[Argh]

@Snipawolf:

1. Tests on various machines (doing pre-Alpha checks on PURE) have revealed that not all video cards will draw CSimpleGroundFlash correctly. I will post this on Mantis; I am fairly convinced this is a z-order bug, but on some systems, the CSimpleGroundFlash simply will not draw

2. In addition, looking at your example there... maybe it's the ColorMap settings, or you have something else drawing in that FX? The order in which FX are called is rather important, due to some FX being z-buffer tolerant, and some of them getting culled if you don't draw them first / last. Rather irritating.

[Snipawolf]

It shouldn't be a color map setting, and I don't have any other FX in that, it is merely something I leave on the ground as a blood stain from killed soldiers.

[Argh]

Then it's probably the z-buffer bug. I have reported it on Mantis, because further testing this weekend revealed that it's often being culled by other CEGs or by GroundScars, depending on what order the video-card uses to do the sort, which appears to differ by card / driver- you'd think this would be standard given that it's OGL, but apparently not.

Try this, though:

Take your blood-splatter file (it's a 32-bit TGA, right? better be) and make the alpha-channel white.

Make sure that your reference is in the right part of Resources.tdf:

Code: Select all

		[groundfx]
		{
			groundflash=groundflash.tga;
			groundring=groundring.tga;
			seismic=circles.tga;
			BrightFlashScar=BrightFlashScar.tga;
			BrightFlashFadeScar=BrightFlashFadeScar.tga;
			BomberFX_front_scar=BomberFX_front_scar.tga;
		}

Now, reference this from your FX, and does it draw?

[trepan]

There is no alpha (back-to-front) sorting In the standard GL pipeline.
You can implement it in a shader in certain situations, but nothing like
that is being done by any Spring routines that I know of.

[Argh]

CSphereParticleSpawner is z-sorted, or at least draws without culling. I was told that whatever was done would be fairly expensive (it's not really that bad, if you're not doing hundreds of them per frame, but meh, you'll see soon enough) so I'm looking for something that behaves the same way, and that would also respect the full capabilities of ColorMap (not being able to do dark colors kind've sucks, was wanting to do custom groundscars with "glowing embers", etc., to give the battlefield a nice, healthy glow)

[jK]

Yeah, z-ordering transparent polies is a banana problem.
I have that problem atm with my lua particle system, especial I use displaylists and a billboard shader, so I can't order the particles at all :/
(only additive blending and a layer parameter for each particles-object limits the problem)

[Argh]

Eh?!? What's up with this? If I'm reading the code right, CSphereParticleSpawner is no different than CSimpleParticleSpawner... in fact, that section seems to have been emptied.

What's up with that? One was supposed to be fast, but not z-sorted, one was supposed be slower, but z-sorted. I've been using them based on that set of assumptions, and they certainly seem to be working right...

Lemme test what happens to my nifty FX if I switch 'em over to Simple, and make sure this is right...

<tests>

[Argh]

Test results:

No real difference in observed behavior!

I can't complain much- unlike earlier versions of Spring, there is no rampant culling going on, literally not drawing the particles (this whole culling / not culling thing dates back to the original Nuke script). However, some particle types are not compliant with this, and get culled still:

Spike

Groundflash

SimpleGroundFlash

And IIRC, the SpherePart and some of the other ones that nobody uses right this second (mainly because I cannot get Sphere to draw correctly in most cases, and there's no variant with the polygon normals facing out, instead of in).

Hmm. Lemme go look at the Groundflash code. If SpherePart is just a legacy and is no longer actually necessary, that's great, and good to know, but... there's gotta be a reason why Groundflashes get culled then. Maybe using older code to draw them?

[Argh]

Hrmm. This is the code where it's declaring how the object's getting rendered. Seems it is rendered twice, so that it's double-sided in effect:

Code: Select all

	float3 normal=n1+n2;
	normal.Normalize();
	side1=normal.cross(float3(1,0,0));
	side1.Normalize();
	side2=side1.cross(normal);
	ph->AddGroundFlash(this);

Ok, so now where do I look for this... lemme check dependencies and see. Gotta be something that causes it to get culled sometimes, because I know that if you spawn a CSimpleGroundFlash and a CSphereParticleSpawner / CSimpleParticleSystem (since so far as I can tell, they're identical now) then I very frequently see it get culled, even though there are only two particles...

[Argh]

Well, the only thing I can think of is that it's something goofy in the VertexHandler code, however, it works fine for other stuff! The irritating thing is that when it draws, it draws correctly. On my machine, it draws 100% correctly, so long as these things aren't happening:

1. If another particle is generated with a very similar radius and position (which sucks, because I very specifically want to do that).

2. If "buried" under other particles, it sometimes draws, sometimes not. It's like something's trying to determine if it's obscured, and is failing miserably. Hey... can GL_CULL or whatever be turned OFF for CEGs? In 99% of the cases, that'd actually speed stuff UP, even though more particles are being drawn...

On some computers, using some video cards, these FX stubbornly refuse to draw. I just tested two days ago at DRB's place, and never once saw them draw. He has a GeForce 7600 in SLI configuration- we tried screwing around with that, and while I was able to get it to a blistering framerate, I could not cure the drawing problems. At home, on my GeForce 7800GT, I only see them get culled under conditions 1 and 2. Here at my parents' house, on a crappy Radeon 9800 variant, they draw just like they do on the 7800GT, albeit at a slower framerate, even though the minimap and some other things still draw with odd artifacts that seem to be related to AA

[AF]

Argh, in settings.exe theres a parameter called z-buffer depth that is either set at 16bits or 24bits. Some cards work well on 24. Some work well on 16. Some cards give issues if they're set to the wrong depth.

Perhaps this is the cause of your issues?