PB4 request, short one.

[Steeveeo]

Just a quick little suggestion for PB4, this one about Planar Render size limits.

For some of my explosions (like my nukes), I need to make a big groundchar to go with it, but when I make it over 400 points wide, the polygons of it go flipping around the screen and causes an eventual crash, but when I set it to 175-250, every once in awhile, it causes an AV if I look at it from a certain angle.

Is it possible, GSH, to maybe remove this limitation and kill the problem with a little bit of your time just before the release of PB4? Or is it an engine glitch that cannot be fixed currently without a massive overhaul of the engine?

[Steeveeo]

This is whats constantly happening

Code Select Expand

[ E X C E P T I O N ]
Patch 1.3pb3 EDITOR Aug 10 2006 08:26:12
Type: ACCESS VIOLATION
Info: READING from 15E915E9h
CallStack:
004FDF50 +0002 bz2edit.exe EXE ConstructionDisplay.obj public: struct VertexTL & __thiscall VertexTL::operator=(struct VertexTL const &)
00505193 +0403 bz2edit.exe EXE PlanarRenderClass.obj public: virtual void __thiscall PlanarRenderClass::Render(class Camera *)
005003B4 +00A2 bz2edit.exe EXE ParticleSystem.obj public: static void __fastcall ParticleSystem::Submit(void)
0049017B +0068 bz2edit.exe EXE GameFeature.obj public: static void __fastcall GameFeature::SubmitAll(class Camera *)
004578C6 +0147 bz2edit.exe EXE  void __fastcall Render_Internal_View_Dynamic_zBuffer(class Camera *)
004579ED +0085 bz2edit.exe EXE i76loop.obj void __fastcall Render_Internal_View(class Camera *)
0046908E +0538 bz2edit.exe EXE ViewCockpit.obj void __fastcall ViewCockpit::Process(void)
005501B0 +0130 bz2edit.exe main runcodes.obj public: void __thiscall RunCodes::Process(void)
0046AB47 +008D bz2edit.exe EXE ViewManager.obj void __fastcall ViewManager::Process(void)
Registers:
EAX: 15E915E9h   CS: 0000001Bh  DS: 00000023h
EBX: 003FB510h  EIP: 004FDF50h  ES: 00000023h
ECX: 00000000h   SS: 00000023h  FS: 0000003Bh
EDX: 00000000h  EBP: 0225F7ACh  GS: 00000000h
ESI: 04F82810h  ESP: 0225F78Ch           
EDI: 00A4F7BCh                       
CF: 00210202h PF:0 AF:0 ZF:0 SF:0 OF:0
Entering critical shutdown


[Angstromicus]

Increase the map grid size by a power of two. Though, buildings that take up less than four tiles of terrain will cause tearing. I may not be GSH, but don't expect that feature until after PB4 if at all. PB4 is close.

[Commando]

Yeah, I wouldn't expect anything but bug fixes from now on until pb4's release.  The main bugs being resyncs.

[Steeveeo]

Um...technically, it is a bug, not a feature, as if the planar texture gets too big, tearing occurs and causes the planar to render over the entire screen in broken polys, and other times it causes an AV, increasing the mapgrid is out of the question, as my mod uses only standard sized stuff.

[GSH]

That's almost certainly running into BZ2's internal limit of 8K verts/24K indices, and trashing memory. PlanarRenderClass is typical offender on this. pb4 already handles this:

- Fix for mantis #890 - PlanarRender could submit too many indices,
which would trash memory. (It'd previously allow this, w/o noticing or
complaining.) Made PlanarRender do a sanity check on how many
verts/indices it'll use before it submits an object. If it would trash
memory, it'll skip that item entirely, and whine to the console. Best
way to fix this: make it apply to fewer terrain cells. [NM]

-- GSH

[Steeveeo]

Is there a way to increase the internal limit with out a complete overhaul of the entire system?

[mrtwosheds]

I found that really big planars just look bad, especially if they go off on hillsides.

You could try something like,

[Render]
renderBase = "draw_wave"
textureName = "twave.dxtbz2"
textureBlend = "one one modulate"
startColor = "255 255 255 32"
finishColor = "255 255 255 0"
startRadius = 1.0
finishRadius = 12.5
animateTime = 0.5
waveAngle = 3.14159// This makes it go exactly 360 degrees!
waveDepth = 1.5//
waveSegments = 24//

I have not tried using one of these on a big scale, this is from a gun of sorts, should be able to modify it to an explosion effect.

[Steeveeo]

problem with draw wave is, that it takes the texture and bends it around an arc instead of flat to the ground like a planar.

Since I am using the planar to light the ground underneath the nuke completely white in one instance, and cannot make it as big as I need it, is there a way to make draw_light have a flag to wash out the color of a specific radius and paint it a solid color?

[mrtwosheds]

is there a way to make draw_light have a flag to wash out the color of a specific radius and paint it a solid color?

Make it very very bright, lights are not restricted to 0-255 values like other colors.

Big planars look bad when they hit hills, wave will go into the hill, it might look good as a shock wave effect.(or maybe not)
You might even want to use
spriteCenter.x = 0.0
spriteCenter.y = 1.0
to adjust the height.

[Nielk1]

We need OM, the DLL wizard, to make some in game render makes.

A repeated explosion and standard attached effect should do well. A few auto fireing turrets too.

Just throw a map together, have the DLL open some CFGs to ask for values and edit the effect ODFs in mem to do what is wanted and save them. The DLL can even make the initial ODFs from scratch. It does sound like a lot of work though.

[Steeveeo]

Make it very very bright, lights are not restricted to 0-255 values like other colors.

Tried that, it doesnt fill the entirety, even with 2550000 or any number of zeros in between.

[mrtwosheds]

A repeated explosion and standard attached effect should do well.

I can't get my head around the fact that the original developers saw no need for chain effect explosions, and put no simple way of creating them into the game.

[GSH]

I can't get my head around the fact that the original developers saw no need for chain effect explosions, and put no simple way of creating them into the game.

Well then, let me suggest you get your head around this: BZ2 1.0 had all of the features that our designers needed to ship the game. Our designers were the "customers" for the game engine, so if they required it, it went in. If they didn't really need it, we were so short-staffed that "it would be nice" features didn't get any time.

-- GSH

[OvermindDL1]

Actually if you look at many game engines there is no such support for things like that, they usually fudge it by having the death of something spawn other little things that have no mesh, but who's life ends after a delay and will cause other effects to happen at time delayed sets.
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey