WorldSpawn official WIP thread

[MadGypsy]

I semi-figured out my problem. As it turns out commenting out all the ParticleFollowNode code fixes my problem but, it creates a new one. Not a big one but, I lose the particle trail. Currently, the away3d ParticleFollowNode script is over my head. I have looked over it for a while but, I honestly have no idea what part of the code is making the "rocket" invisible within the map bounds. There is an awful lot of code and it's almost entirely AGAL (adobe graphics assembly language).



I'm going to tighten my code up (not the above, that's ParticleFollowNode from away3d code) as much as possible tonight and move on to other things.

[MadGypsy]

I tightened the script up quite a bit. It totally works inside a map. However, this version is a pretty long range "weapon" so I chose to go way out in the skybox so I could better represent some stages. This will not break by speed tapping fire. Every time you hit fire a new dictionary entry is made storing the new bullet, the current time + 2000 and the current camera forward vectors. It's probably impossible to get anywhere even close to filling the dictionary in 2 seconds even if you just held down fire (which will currently rapid fire). At the end of the 2 seconds the bullet completely destroys itself and is removed from the dictionary.

It's still starter-kit stuff but, it is improved starter-kit stuff. I made sure my script could easily be extended to be more advanced, without having to fight with the current class or overriding it to death.

[MadGypsy]

This is more about trying to find good settings for cam studio than anything but, here is a little vid of me "firing bullets"

[ame]http://www.youtube.com/watch?v=6WxhubbiclM[/ame]

[MadGypsy]

Doing now/today:

mouse lock (fullscreen-only) - allows the mouse to be used for freelook without mouse-down interaction, by essentially making the screen infinite. ie, moving the mouse to a border does not "max" mouse co-ordinates. This can only be used in fullscreen because flash does not allow me to use the mouseLock feature in windowed mode. There is pretty much no way around this. Imagine: you are in windowed mode, you move the mouse past the player bounds and click to fire...you have just lost focus on the player. Because flash tries (and does a good job) of not overriding common system features, there is no way for me to completely hijack the cursor and lock it to the player bounds or any other such thing.

rework CompactSubGeometry - when I posted about interleaved buffers on numbersix's thread I realized that Away3Ds CompactSubGeometry is wasteful for my needs. The implication of this rework is deep and huge. changing -

[v,v,v,n,n,n,t,t,t,u,u,u2,u2] to [v,v,v,u,u,u2,u2] will need to be cascaded throughout numerous points in the API and I promise you I am going to break the fuck out of this about 100 times before I get it to work. However, I will do this without modifying the API at all. I will clone all the necessary classes, rework them and point my engine to the clones. This way, if I ever need normals/tangents in my comSubGeo, I can simply make an exception and point my code to the originals.

More aggressive compacting - currently anything that is not worldspawn is compacted. I think an exception should be made within my texture batches that's something like

if(((vertices.length/3) * 7) < 65536) compact = true;

the /3*7 part is to accommodate this [v,v,v,u,u,u2,u2] (7 indexes per vert - once I rework comsubgeo)

I'm moving right along so, hopefully this stuff will be done in a few hours (EXTRA HOPEFULLY reworking compactSubGeo)

oh I added a crosshair. It's stupid and lame but, my method is always groundwork/advance/optimize/extend. I'm at groundwork on this one.


It's a hair too high because I told bullets to start a little lower than the center of the screen but, I didn't tell the crosshair to do that. For good reason, too. The crosshair shouldn't be hardcoded to be anywhere. The crosshair should be flexible due to what you expect the current bullet type to do. That's why this is lame and stupid. It's just a picture of a crosshair centered on the screen (currently).

[MadGypsy]

sweet! For this map at least, I am now using 59 compacted buffers instead of 177 non-compacted ones. It all depends on how many verts are in a texture batch for compacted results but, in the case of e1m1 at least, the entire world can be compacted. However, until I rework compactSubGeometry I am actually using double the verts.length with "zero data" due to tangents and normals being stored in the compact buffer. I looked at the code I need to rework. All I can say is...:sigh:. It's a whole fuckin lot.

[MadGypsy]

Remember this from a couple of days ago? That's the bounds for every texture batch and every entity.


While digging through all of the Geometry and Mesh related classes to gain the scope so I can modify it, I realized some things about how the Away3D API is assembling things. I broke my lightmaps in transition but, look at the new results (regarding bounds).



I'm about to get on to fixing the lightmaps. After that I have a new gameplan to pursue. Now that worldspawn is considered one big entity I can completely get rid of it's bounds (or at least shrink them down to practically nothing and move them completely out of the map). The reason is simple. For whatever reason, "rocket trails" do not like being visible inside of a another models bounds while the camera is also in that models bounds. If I invalidate the worldspawn bounds the "rocket" won't know it's inside of anything. I don't need the worldspawn bounds because collision detection is done through the bsp nodes.

[MadGypsy]

Oh...the implications go beyond worldspawn. Remember this


Even though that is acting as one, it is still considered 2. Ignore my currently borked lightmaps and notice that now entities really are 1.

[Mugwump]

I won't pretend I understand anything of what you're saying here, it just looks like quite the phenomenal optimisation.

Nice new signature. Is it Megadeth? It's been ages since I've listened to Rust In Peace but I remember a similar line in Holy Wars... The Punishment Due.

[MadGypsy]

Thank you!

@megadeth - yeah

@ what I'm saying

Imagine if you had a map that was only 2 textures (regardless of the amount of faces). In my old method that would be 2 different models (one for each texture). Now however, (assuming both textures were part of one entity) the 2 textures become 2 subModels of 1 model. It's not so much an optimization as it's just better organized. Now, I can talk about worldspawn in my code as a whole instead of 50zillion independent models.

Unfortunately though there is a bug. My code is right but the lightmaps are fucked up. Somewhere in Mesh/SubMesh my secondary UVs are getting lost. I didn't write the (Sub)Mesh codes, Away3D did so, I have to solve an error they made. It's weird though cause some of it is right. All that red in my pictures is because my lightmaps color deadspace red. So, the lightmaps are definitely "working". The secondary UVs aren't...sometimes. I'll figure it out.

[Mugwump]

Cool! I was sad to hear about Nick Menza. He was one helluva drummer. Rest in peace... Polaris.

[MadGypsy]

sigh... I have come all the way from the top of the renderer to the bottom of subgeometry and every super and interface along the way, I cannot find the glitch with lightmaps.

it's kind of pissing me off...

[MadGypsy]

Hell Bent - Never Relent



I know what you may be thinking... "It's still broke". Well, sort of. Any texture with a transparency less than (1) is broke but, it's not really broke. It's just, not fixed. It will be though. Ya see, all of those transparencies are set with something like material.alpha = .5 and material.alphaBlending = true....


The lightmaps work...all of them. The lightmaps are set with a shader via material.addMethod(new QLightmapMethod())

so, I need to change (ex) material.alpha = .5 to material.addMethod(new QWaterMethod())... as soon as I actually code that method. And everything will be fixed. If for some reason that doesn't fix it, I have already thought of a number of other solutions.

1 solution could be utilized perceiving this is a mixed contents problem and simply separating SOLID, LIQUID & CLEAR brushes into their own meshes. This assumes that the problem I am actually having here is that materials can't have different transparencies within a singular mesh but, that doesn't mean they can't have the same semi-transparency within a separate mesh.

This map will be 1 bound per entity whether it likes it or not.

EDIT: I totally spaced about what I did to fix lightmaps. I was never able to find the mistake in the away3d code (it's there somewhere) so, I wrote a function in Mesh that populates the geometry and submeshes vectors a different way. I didn't change my code at all, other than to point it at the new function.

EDIT2: about what I said regarding separating the brushes. Of course that will work cause it will just be reverting un-lightmapped surfaces back to the way I was already doing it BUT before they would have been further segregated by texture. In this case they would be segregated by transparency. It should still work. I'm not going to do this unless I can't solve it with a shader. Essentially this way would split worldspawn into 2 entities (liquid/solid). Invisible entities are already their own entity.

[MadGypsy]

Due to the last edit of my previous post, I realized something. All those triggers were not a mixed content situation. They are their own entity and the alpha was still not working. The solution was simple. I told parent meshes to inherit the material of their last processed submesh. Submesh materials override it's parent material so, assigning the parent a texture does nothing to the submesh. Except, by now having a material of it's own with the same transformations as it's children, well...you can see in the pic.

Unfortunately, this approach does not work in a situation where there really are mixed contents. My only compromise is that liquid is it's own entity. No matter how many different liquids, they are one entity. What you are seeing above is the submesh for liquid inheriting the need of a lightmap and there is no lightmap for liquid so the texture has a lightmap of "NO_TEX".

By converting all liquids to one mesh and using my same trick from above with assigning it's parent the same material. I get transparency back. The slime and the water are "one".




I think the final results are pretty clean. The only thing outside of what I wanted to accomplish is having the water separate. I can live with that. Liquid could easily be made to flood or drain. Not independently, though.


compare


This was all probably one of those "million hornet" situations baker described in my other thread. Those lil' bitches never win.

Now, I'm going to practically remove the bounds for water and worldspawn and add "rocket-trail" to my "bullet", which should work when it and the camera have no bounds to simultaneously occupy. I intended to make my "rocket-trail" first so, I will test it before removing any bounds. Maybe the problem was that it didn't like being in a shitload of bounds simultaneously. Bounds definitely have something to do with it due to one simple fact. Outside of bounds it works, inside bounds it doesn't but, like I said, I was in tons of bounds so, we'll see if that was the problem first.

[MadGypsy]

Well, I made a cheap rocket-trail and I told the map that it's bounds are that sphere. Shit still doesn't work inside the map.

[MadGypsy]

I told you it had something to do with bounds. Since "nullifying" the worldspawn bounds didn't work. I "nullified" the rockets bounds. I'm sure this is gonna be some kind of a problem later. I'll worry about that when I get to it.

note: I know my "rocket trail" is terrible. That's not the point.