I have thought of q3map2 feature some time now and I like to start discussion at least, if not feature to q3map2 compiler sometime.
The VIS stage has been pain allways to optimize with hints and areaportals. I haven’t even able make them work btw. (game ET) So I have though of new portal type: distant portal. It would work so that if player is far enough it would block VIS otherwise it wouldn’t. The distand could be defined in entity keys so that it would be versatile. Maybe the portal would show some shader if it blocks VIS so possible HOMs would be avoided.
I think that this would help to create big outdoor areas and block VIS going inside buildings placed in windows and doorways. Maybe they would rock inside door brushes too.
What do you think? Is this even possible to code ydnar?
I would like also to see something like distant_portal_switchable… I image this like being 2 entities and the if the player is in one the other gets visblocked. i have already written an email to ydnar about this some months ago, but actually I don’t know the progress/status on “manual vis entities” integration in Q3map2… ydnar. maybe u gonna post here a quick comment on this? btw. what happend to the auto hinting feature? will we see that in future releases?
thx for your support pazur. Maybe you scared ydnar away with your tricky questions.
Anyway is there possibility to see some new neat VIS features in next q3mp2?
Hm. Farplane culling works with fog because the foghull shader ‘fills in the gaps’ where the faces aren’t drawn, so basically you want the same thing only without the fog, yes? Also a portal as used in a teleporter operates the same way. Question is: what shader would you use if not fog? What will look right?
As for the house: sounds like what you want is a glass shader for the windows that works in a similar way to the teleporter portals, i.e. only lets you see through it when you get close up, otherwise it’s opaque. TBH this sounds distinctly do-able.
A shameless BUMP !
pazur noted this thread in SCDS_reyalP’s thread so this old idea came alive again. To make a note this similiar kind of feature is in Source engine. Ex. There can be glass in a window that comes see through when near enough.
Well, as described, I don’t see how this could be done in the compiler without engine support.
I suggest reading through http://graphics.stanford.edu/~kekoa/q3/ and look at how vis data is recorded. Now understand that all the compiler can do is set whether a given cluster can see another cluster. It certainly can’t “program” it to change at runtime.
That said, I have some ideas for some really ugly hacks that might let you do something a bit like what you want. I’ll have to dig some more to see if they are workable. Even if they are, I suspect they will turn out to be a bit of a gimmick in most situations.
It is, and without new compiler features – just use alphagen portal in your glass shader.
(Unless q3map2 doesn’t actually treat alphagen portal surfaces as blocking vis between leaves on opposite sides when one of them is further from the portal than the opacity distance, but in that case alphagen portal would be pointless wouldn’t it?)
Engine support isn’t needed to get this working in, say, Q3 – so long as the portal doesn’t move of course. And if it does it’s an entity and won’t block vis at all anyway.
If this represents a chain of clusters with one of these portals:
******|
Then the compiler just has to output vis data that says the clusters changed to hashes in the second version below can’t see the clusters to the right of the portal:
###****|
Normal vis would say they could, as there’s an unbroken line of sight, but the engine will not care. The only problem is you will get hom unless the shader at the portal has opaqued by the distance to the first #, which is possible using alphagen portal.
In fact, I was fairly sure vis behaved this way when it saw alphagen portal surfaces even in q3map1, since there didn’t seem to be much point in alphagen portal if it didn’t actually reduce the hit a portal made on your polycount when it was far away. I figured the idea was a close by portal means not much nearby geometry is in view – maybe just a fairly plain wall and some floor and ceiling – whereas when you drew back to bring more local geometry into view, the remote geometry in the portal view would quit contributing to the scene to compensate.
Also, _farplanedist obviously works similarly. It just alters the vis data to say no two clusters can see each other if they are more than some distance apart. So there is no engine limitation against having vis data that treats something as transparent for some pairs of clusters and opaque for others. The only problem is you get HOM if that something doesn’t actually become opaque at the latter times. Alphagen portal does, and fog also does.
The tricky thing is that alphagen portal will still HOM without a portal camera, and fog will still HOM without the proper sky shader/whatever it is used to back the fog.
With the window thing, this means it’s not as simple as just using a glass shader that uses alphagen portal and blendfunc blend. For a simple rectangular window pane, you need clip on the four sides facing into the windowframe (so it agrees in contents with the others – trans, not nonsolid – but won’t cause overdraw or Z-fighting when you see it by looking into the window at a shallow angle), an inner side with a normal glass texture, and an outer side that’s really a portal, with the misc_portal_camera just inside the window and facing in. Just set the angle key since it will probably be axial; target it from a misc_portal_surface near the window; and remember you can’t have portals see into portals (at least not circularly). Four windows that line up diagonally in an L-shaped building present the most obvious potential for trouble, since the nearer portal will look into a corner of the L, through a window (seeing the normal window shader facing in, not the portal shader facing out), and then into – uh-oh – a second portal surface on the exterior window in the crook of the L looking into the OTHER corner of the L.
There’s two other cases where this sort of vis trickery can work without HOM. One of them is where there’s an actual wall. For example, _farplanedist should work fine in a map with no sightlines as long as the _farplanedist, even without fog. Of course, you can probably get as tight a PVS using hints in that case. And then there’s if you can somehow combine the use of alphagen portal (instead of fog) and sky (instead of a portal camera) to make sure the engine has something to render behind. (One supposes an opaqued portal gets a pair of triangles instead of the full complexity of whatever geometry the portal camera sees.)
Also, it’s interesting that the whole initial discussion took place in 2004, and when later that year Half-Life 2 came out its “source” engine had exactly this feature – on any of the large terrain maps with houses and stuff, the windows are all opaque from a distance but some become transparent when you get close and show the interior.
alphaGen portal and _farplanedist don’t work the way you think they do.
alphaGen portal works exactly like a camera and a video screen. You place a camera in one area of the map and the portal in a different area. The portal basically draws whatever is displayed from the camera. With distance, it culls what you see in the camera with the portal image. It does not dynamically change visibility across vis portals.
_farplanedist does not dynamically alter vis data or clusters. _farplanedist basically creates a great big box that surrounds and moves with the player. It instructs Q3 that everything outside of the box should be culled.
Nothing dynamically alters vis. Yes – I know this. But the static vis data is made so as to consider certain widely-separated clusters unable to see each other, where otherwise they would be. What changes dynamically, as always, is the PVS as you move from leaf to leaf; the PVS for one leaf doesn’t change.
By the way, avatar uploading is broken. I tried to upload a gif and it choked and said “only gif, jpeg, and png images”. Uh – it was a gif.
