Mapping question: 'solids'
#1
I want to ask from a developer point of view: Are 'solids' meant to be/act like portals in order to determine the surface visibility? I've just read this docs and just wanted to be sure.
Thanks given by:
#2
Solids, act like blockers of visibility. That's why they're your number 1 tools, to avoid map lag.
Thanks given by:
#3
(23 Mar 13, 08:22AM)RandumKiwi Wrote: Solids, act like blockers of visibility. That's why they're your number 1 tools, to avoid map lag.

So this 'solid' blocks are being used to determine surface visibility? Are these being used as portals? What surface visibility technique is used in AC?
Thanks given by:
#4
I have no idea what you're trying to ask.

Solids block visibility. Go into a map, hit editmode. Fly above the ceiling of the map, then, type /toggleoccul

You'll see what the solids do if you turn that on and off.
Thanks given by:
#5
My questions are oriented towards the internal workings of the AC engine, and are directed to AC programmers so this is a technical question rather than a tool-usage question, perhaps this isn't your developing area inside AC dev team so that's why you don't have idea of what I'm asking. Looking forward if another AC dev can answer me.

Not sure if this is the appropriate section for this post. Fell free to move it where you see fit. Thank you.
Thanks given by:
#6
Solids are used for occlusion/culling. Any polygone, which is located behind a solid face will not be rendered. That's it. The lack of solids will cause the engine to render a whole lot of stuff which isn't visible to the camera anyways.

Hope that's what you're asking.
Thanks given by:
#7
Sorry but no, it's not what I'm asking. Perhaps I'm not explaining myself by assuming AC devs do know the AC engine from inside out, if this is the case please do tell me so I can restate my question so you can understand. To me it's a very basic question when it comes to a basic structure of a 3d computer graphics game, that is, visibility determination.
Every game do make optimizations to send to the gPU the less polygons as possible and this is the purpose of 'solids', I already understand that, but what I'm asking is HOW or what technique is used to accomplish the said occlusion. I also already know AC uses a geomipmapping technique but I was wondering if AC has another oclussion/culling technique besides geomipmapping, I was in the hope an ac dev could tell me how this is implemented in AC, after all they should know the AC engine, they are maintaining/developing it. The source code is somewhat hard to follow and not so well structured, so I wanted to ask to an AC programmer before diving deeply into the code.
Thanks given by:
#8
As far as I know, no other occlusion technique is used.

The AC codebase is pretty big, and not very well structured. For example, I recently found the command and code for "togglegrab" was in the bot code. Because, you know, access to basic SDL functions is totally relevant to bots.
Most of the devs working on AC right now have not been around long enough to know the entire codebase, and understand how it all works. Probably the person with the most knowledge would be eihrul, who would probably know mostly about the cube code (so, the bulk of it). Throughout the rest of the dev team everything is pretty much covered in terms of knowledge it seems. If a dev doesn't know something, they figure it out for themselves.

If you think about all maps that get good performance, they include a lot of solids and the style of the map makes it seem natural.

If you want to learn more of the occlusion, I suggest reading up some material on the cube wiki: http://cube.wikispaces.com/ (which iirc includes some history), or the creators wiki: http://strlen.com/ (which iirc includes some talk about what he was doing). I remember reading a bit about what Wouter did in terms of occlusion, however I forgot where I found it.

If I had to guess about another form of occlusion that was happening, I would guess that the fog would be doing some. I'm not really sure though.
Thanks given by:
#9
That's an unfortunate and sad answer. If that is true, then I guess I better start by world.cpp and see what comes up I'll post what I find if anyone interested.

Edit: no, generally the fog is used to disguise popping artifacts, that is, making less obvious when objects/geometry enters the viewing frustum therefore rendering the said objects/geometry all of a sudden, silent hill for the psx and lots of others used this technique (even today's AAA games do it). In AC, it's seems to be the case by looking at the code.
Thanks given by:
#10
Sorry, I obviously didn't get your question right. Now I see where you're coming from.
Thanks given by:
#11
(23 Mar 13, 02:57PM)TheNihilanth Wrote: That's an unfortunate and sad answer. If that is true, then I guess I better start by world.cpp and see what comes up I'll post what I find if anyone interested.

Edit: no, generally the fog is used to disguise popping artifacts, that is, making less obvious when objects/geometry enters the viewing frustum therefore rendering the said objects/geometry all of a sudden, silent hill for the psx and lots of others used this technique (even today's AAA games do it). In AC, it's seems to be the case by looking at the code.

Well most often we don't have to mess with the engine itself, that's why our answers might not be as accurate as you might have expected.

Basically, it seems to be based on a simple raytracer. (which can be "disabled" with toggleocull). On each frame, the engine traces 512 rays from your position all around you and for each angle it stores the distance from you to the nearest solid wall.
(worldocull.cpp:void computeraytable(float vx, float vy, float fov))

The ray table is then used by isoccluded(float vx, float vy, float cx, float cy, float csize) (same file)

According to "CUBE TODO" log in the source, it was considered long time ago to replace this system by a quadtree algorithm.

(So, to answer your first question: yes, solid walls determine how far the camera can see from its location)
Thanks given by:
#12
Hmm, looks like there's some potential for optimizing the render code. Though, just thinking of the kind of maps causing bad perfomance (open fields with barely any obstacles in it), I highly doubt a more precise occlusion system alone would change much. I guess the LOD system would require some tweaking, too.
Thanks given by:
#13
Indeed it do requieres optimization and one of the reasons I asked is because I'm working in something related ;) I think there is a good possibility to make it more efficient therefore gaining more frames per second. Only tests will tell tho.
Thanks given by:
#14
Well, feel free to share whatever you come up with. :)
Thanks given by:
#15
Sure, but don't hold your breath xD that would lead to a different engine tho.
Thanks given by: