Q1 BSP tree

[Cobalt]

Can anyone here explain this or add to my impression of it? I had chatted with LH about it and from what I understand its responsible for how Q1 detects collisions with respect to setsize in that, only point ,player and Shambler size hulls will perform a collision. As a side note, I have concluded that you CAN setsize to any size within reason and dont have to stay in those bouinds as long as the ent is NOT moving. The collision issues where objects start falling through walls haphazardly happen when they are spawned inside another bounding box of another ent or are moving with a non point, player or shambler size.

Lord Havoc says that the Q3 map tree has resolved this and it will detect any hull size collisions. Is there a way to "hack" this in the q1 engine so that all the sizes are collidable in the same way , or would the maps have to be converted to the q3 system?

[Spike]

Q2+Q3 don't actually use the bsp tree for collision, it only uses the tree to efficiently find convex brushes against which you might collide, this means that it can safely follow the wrong nodes and no actual harm comes from it.

Q1 uses pure bsp collision and as a result contains 3 separate bsp trees, not just one - point, player, shambler. the brushes that originally formed the map are expanded by the size of the hull before the tree is built. But the real pain is that the most precise tree - the point tree - has the clip brushes removed. clip brushes work by only existing in player+shambler hulls, thus allowing point-sized projectiles through but not monsters nor players.
this is the same problem you find with polygon collision methods too.
While its possible to convert a Q1 map into a Q2 one, doing so always looses the clip brushes, and that often makes the map not worth playing as you end up getting stuck on every corner.

For comparison, doom didn't use its bsp tree for collisions at all. Doom used a 2d blockmap thing that has lists of the various linedefs embedded in them. it just does 2d 'poly' collisions, and its players are cylinders.

[Cobalt]

Thanks Spike.

So I guess its possible but with alot of work.

When you explained the 2d Doom collision thing, it reminded me of the funct in QC EntitiesTouching (), which is what the doors use to detect collisions with each other I believe. I recently modified that code to detect collision with absmin / absmax which seems to me more or less how a .touch field works , at least in my experience. Why couldnt we call a funct like that every frame as the ent moves and compare to world for example, and do collision that way?
Or is this really just the same problem again?

[frag.machine]

You can split collision handling in Quake in two approachs:

a) entity versus entity - you can set any arbitrary AABB with setsize(), and the engine will use it (be aware though of details like MOVETYPE_FLYMISSILE adding 16 units to the AABB you specified, for example);

b) entity versus world - as Spike said, your AABB is rounded to point, player or shambler size, and collision is tested against the appropriate hull. The relevant hull info is retrieved walking thru the BSP tree.

BTW I never understood why Quake just dont always use the point size hull for collision. If I understand correctly Q2 and Q3 just work this way. Is there any real advantage in terms of performance or memory usage to use the point/player/shambler scheme ? Or was it just a weird idea that could not be ditched without screwing legacy maps ?

[Spike]

[frag.machine]

[Cobalt]

[Cobalt]

[Spiney]

Q3 lightstyles are fairly usable, they're simply shaders generated by the compiler.
As such, they don't influence the lightgrid and take some perf hit (though should be fine on a modernized renderer, i suppose).
http://q3map2.robotrenegade.com/docs/sh ... tyles.html

Q3 bsp and Q1 toolchains/mapping culture don't mix that well though.

*upd: triggered shader...
http://www.simonoc.com/pages/articles/trigshaders1.htm
http://www.quake3world.com/forum/viewto ... 10&t=44384
tl:dr; globally triggerable shaders in Q3 = sure, triggerable lightstyles in Q3 = nope.

[Spike]

q3 lightstyles are perhaps usable, but they're still not switchable.
wads+textures is another issue for Q1 mappers trying to create Q3bsps instead, which is probably a bigger annoyance to anyone trying to make q3 bsps with a q1 .map tool.

[mankrip]

Very informative thread. I always forget to think about the collision hulls stuff, even though they make it harder to create games with different gameplay.

Q2 BSP seems to be the way to go for original games. Still familiar to Q1 mappers, but without such gameplay limitations.

[Cobalt]

Hrm, thanks to those who replied. I guess there really is no upgrade or modification possible either via an engine hack or alteration of the BSP spec that would resolve the clipping issues or collision issues I was looking to overcome. Sounds like any attempt to do so would mean rewriting many things and simpler to use q2 or q3 map formats...however to my knowledge the original Quake ID maps have not been converted to any of those and I am guessing its just not possible to do so.

[Dr. Shadowborg]

[goldenboy]

It is quite possible to convert q1 -> q3 and the Quake maps are GPL anyway.

[mankrip]

Dr. Shadowborg: It's only a problem if you distribute the registered episode's textures with them.

Use some placeholder textures with the same names instead, and you're fine.