Transparent textures on worldbrushes arent handled correct. This screenshot is not what it looks like ingame, there you actually see the pink color.

When doing this with func_illu/wall whatever, all is good. 

http://imgur.com/ML7nVBh 

ignore me as usual.. 

QS 0.90 draws this "correct"
http://imgur.com/JYx8dDG 

Will fix.

I was going to remove alpha masked (fence) texture support on world brushes because it is technically wrong and leads to mapper newbie pain (a mapping newbie guy always says "I see void").

Then you guys made a map using it and then Quakespasm copied the Mark V implementation.

So now my "correction" becomes "bug".

Anyway, when I revisit I will "re-add" that back in. 

Its all cool Baker, i was trying to not overuse func_illusionaries for performance reasons, but yeah, its wrong to do it like this i know..
Thanks for your precious work anyway, it is very appreciated! 

I would just make them func_wall/func_illusionary on new maps, and consider the fences-as-world-geometry support in qs deprecated / not recommended for future use.

arguably I shouldn't have added that to qs 0.90, because you'll get HOMs/a view in to the void if the brush touches the rest of the world, plus vis might cull stuff behind the fence texture because it thinks they are opaque. 

Anyways, sorry for this Baker, I take responsibility for spreading the mis-feature :P

mfx, it should be safe to go crazy with a lot of func_illusionary, unless you're measuring a performance hit.

In glquake/fitzquake the brushmodel drawing does a bunch of setup per-poly of the model, so you want to avoid a single very complex func_wall (this is fixed in qs 0.90 though, and probably engines with more advanced renderers). But on the other hand, I'd expect drawing a lot of simple func_walls/illusionaries should be fairly fast on all engines. They're vis-culled too, so even having several hundred spread around the map should be fine. (famous last words.. ) 

the visculling is another thing that prevents this usage. My nooby brains was thinking "when i keep this brushes small and "freefloating" and use them like decals for wall deco and such, that would be cool for blending textures..." 

An option - if you want to have better performance but still let people go nuts on them - is to merge them into the world model.

As a general rule this is safe to do. Inline brush models only appear once each, are already in the worldmodel surfaces/textures/etc lumps, and if they have the same animation frame as the world, and origin and angles of {0|0|0}, you can add them to the world model texture chains quite safely.

For id1 maps there is no measurable performance gain, but for cases where using lots of them is a bottleneck, it works well. The only cost you'll pay is in overdraw, but you can set up the chains so that the inlines are drawn first and then you'll get early-Z rejection on the world polys.

The exception of course is when someone post-processes a compiled BSP to allow sharing of surfaces between inlines and inlines, or inlines and the world. But that would be evil and we'll assume nobody does that, right?

(As an aside: the way stock Fitz handles texture chains doesn't permit this optimization. I can't remember right now if it also sorts it's chains back-to-front (like stock GLQuake does) rather than front-to-back (which would also run faster).) 

If the user wants to make bad content with a feature, let them. No engine coder ever blocked the use of, say, fog 1.

Protecting the newbs seems like a strange reason to limit the feature as well. Why not disable map hacks while you're about it, just in case.

mh's solution sounds good, basically handling the process better. Just disabling stuff seems like prohibition.

Yes, my last map did have a couple of wafter thin parts of void clipping caused by this issue, but it was my fault :) 

thanks for the tips, will play with the merging brush models into the world sometime.

Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array - there's no R_RecursiveWorldNode - then reverses the order per-texture from the chaining. Not sure if cl.worldmodel->nodes has any meaningful order to it.

ijed, that's a good point. 

the idea was that iterating a list is much better on CPU than walking a tree, and the order wasn't that important. This idea was taken from darkplaces at the time.

I have no idea if it's the correct tradeoff with current hardware. If GPU bound I guess front to back would be best. 

Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array

The big problem is that it only regenerates texture chains when the PVS changes. Merging brush models really requires texture chains to be regenerated each frame.

It's actually quite trivial to write a GL renderer that runs twice as fast as Fitz on ID1 maps (much more on big maps), but much of that is down to batching rather than BSP tree traversal (this isn't including dynamic lighting which is it's own separate problem).

So adding some good batching and accepting the CPU overhead of building the chains each frame is a reasonable tradeoff that you're going to come out on the good side of on any hardware (unless you're totally fillrate or ROP bound, which the original 1996 hardware was, and therefore none of this was a problem back then), and then you get the ability to merge as a bonus. 

Any progress on fixing the vs2008/OpenGL build of the latest snapshot? I'd hate going back to r15 after all the improvements which have been applied since then. 

any chance you can post the source for that last snapshot Baker? (no rush, just curious to have a look at it) 

@ericw -- of course! I'm deep in the middle of possibly finally handling some frustrating math calculations that have been owning me all week at the moment, will upload first opportunity tomorrow.

@nightfright -- Don't want to promise a timeframe at the moment. At same time, I do want to get a revision out. 

@eric w -- source 

 

Also: There needs to be an SDK folder above the source code with this. Contains DirectX, Curl, a very heavily modified "FDFramework" (the Mac build was derived from Fruitz of Dojo), some headers and some things moved out of the engine folder.

(More complex than I prefer ...) 

Getting Quake Error
R_Renderview: NULL worldmodel
When pressing F9 to quickload after previously saving with F6.
Fitzquake mark V 0.94 

try again without any mods 

Any idea how to get this to work?
I just can't it working in FQ, but it seems to work fine in quakespasm. 

Can't work out why this is happening. Workaround: put the following in autoexec.cfg:

bind "F6" "echo Quicksave...; wait; save s0 "
bind "F9" "menu_load "

So the top save slot is the quicksave one. 

can you try this:
in the console, type load quick.sav

the 'load' command can load any save by filename and quicksave just saves to a quick.sav file. There should be no difference between loading a normal save and loading a quicksave via quickload. A crash there would indicate something up with quickload code? Or the order in which things are done with quickload vs load??