Spheres? more than 7 sides?

[Demolution]

I was just wondering why is it that a sphere can only have 7 sides? Also some other shapes can have only a limited amount of sides. Why is that?

[Samurai.mac]

To prevent rendering excesses of tris (Q3 is old, computers back then wouldn't handle much more) Try using bevels, or curve cones if you want smooth spheres.

[Lava Croft]

Get a cone-shaped patch mesh and pull the tip/pointed end downwards, so you get one half of a sphere shape, copy paste and flip horizontally, and you have the other half.

I think this is mentioned on these forums somewhere.

[Samurai.mac]

Yep, just most forum users these days have forgotten the ancient art of searching.

PS. Lava, are you a mapper yourself? You seem to be very active in the mapping sections but I don't recall seeing anything of yours.

[Demolution]

I knew there were other ways to make a sphere... I did search. However I was just wondering why this was. Also, since the olden days, why hasn't this been fixed to include more sides? I mean there have been new versions of radiant, couldn't someone have implemented this?

[Lava Croft]

@Demolution:

Because brushes are not fit for detailed curves. Patch meshes have a dynamic level of detail, so that they will use up much less tris when viewed from a distance. Look below for an example, using the Mass Driver zoom.


Notice the patch mesh pipe and attire at full, curvy goodness.


And now from further away, notice how the curvy goodness of the patch mesh pipe and attire has been reduced.

As you can obviously see, this helps the overall performance of your map a lot. Also, patch meshes do not interfere with the calculation of the VIS in any way. However, be timid with your use of patch meshes, and try to use brushes as much as possible.

[Demolution]

Thanks for the advice. I'm sorry to be asking somewhat dumb questions, but I'd rather know, than not.

[Lava Croft]

Asking questions is not a problem at all, as long as the people who are supposed to answer do not get the idea you are being lazy

[Demolution]

I always search before I ask here, but sometimes I search for the wrong things and still end up asking a stupid question... 

[==Troy==]

The problem with patch mechs is that Q3 engine sometimes ignores the collision check of an entity with the patch mech.

For example, there are a few very common bugs in WolfET, where you can fall through a cylindrical patch, and stay inside it, shooting everyone around, whlist noone from outside will be able to kill you.

These patches also cause a lot of bugbuild situations in Tremulous, and most famous thing is the "invisible" buildings. Which appear even on a simle design  of dual-layer patch mech combined with a brush as a second layer. (causes the model to stick to the brush, but the actuall bbox stays on the patchmech).

Moreover, brushes are easier to handle in the sence of hollowing them and just shaping them without being afraid of letting the player inside the volume.


But as Lava mentioned above, the patches' advantage is the higher performace. A 32 sided sphere can cause quite large impact both on the framerate and your compiling times of the map.


As for creating >7 sided sphere, if you open a map file with a text editor, you will notice that the format the brushes are saved is quite easy to reproduce, and writing a simple script to calculate you the trigs for the sphere, and save it in a map file which then you will import will solve the problem.

Edit : And in general, building on patches has always been very buggy.
Edit2 : slight offtopic, but have a look at FATE program at wolfenstein-enemy territory forums.

[Lava Croft]

To cut down Troy's nice explanation to a shorter format:

Only use patch meshes when you absolutely have to. In just about all situations, going with brushes is the better solution.

[Demolution]

The problem with patch mechs is that Q3 engine sometimes ignores the collision check of an entity with the patch mech.

For example, there are a few very common bugs in WolfET, where you can fall through a cylindrical patch, and stay inside it, shooting everyone around, whlist noone from outside will be able to kill you.

These patches also cause a lot of bugbuild situations in Tremulous, and most famous thing is the "invisible" buildings. Which appear even on a simle design  of dual-layer patch mech combined with a brush as a second layer. (causes the model to stick to the brush, but the actuall bbox stays on the patchmech).

Moreover, brushes are easier to handle in the sence of hollowing them and just shaping them without being afraid of letting the player inside the volume.


But as Lava mentioned above, the patches' advantage is the higher performace. A 32 sided sphere can cause quite large impact both on the framerate and your compiling times of the map.


As for creating >7 sided sphere, if you open a map file with a text editor, you will notice that the format the brushes are saved is quite easy to reproduce, and writing a simple script to calculate you the trigs for the sphere, and save it in a map file which then you will import will solve the problem.

Edit : And in general, building on patches has always been very buggy.
Edit2 : slight offtopic, but have a look at FATE program at wolfenstein-enemy territory forums.

Couldn't this problem be fixed in the engine? Moreover will it be fixed for 1.2? Or is that just wishful thinking?

[==Troy==]

Its not a wishful thinking. There are 2 pretty much separate methods for collision check with the patch and the brush. Generally speaking the brushes have volumetric check, the patches, on the other hand, do not.

And fixing the problem is on the line with having oriented bboxes and generally nearlly re-worked engine. I cannot even tell you who can do that from the Tremulous community (based both on skill and time available)