A Quick Shout
Page 4 of 7

Author:  affine [ Mon May 14, 2012 4:47 pm ]
Post subject: 

Cool man :) I have a very creative idea for attracting lots of talent and (hopefully) raking in loads of cash. I'll send you a PM with regard to it.

With regard to the editors, I was planning on having multiple different editors. I learned this from Bitsquid (I <3 their dev practices.) It'll help confine bugs, improve performance, and even improve maintainability. So there will be a Radiant-like tool for mapping. Unlike Bitsquid, however, I'll probably have lighting as a part of this tool instead of having a separate editor.

Here's a pic of the Bitsquid "Tool Center"[/url]

Author:  cqbdrug [ Mon May 14, 2012 11:24 pm ]
Post subject: 


just my 2 cents

..its really nice to read about tom's doing's here ... i never lost the hope of a never ending story of tce ... and really cool he awaked coroner :) very very nice ... i hope you both make a new fresh coding dev team and tce will grow up... mappers, sound makers, modders etc are enough here :) inclusive me i will also work for free for tce....

cause there is nothing else like tce on the marked and tce is a part of my life xD and many many others :)

thanks for reading
best regards

Author:  affine [ Tue May 15, 2012 2:54 am ]
Post subject: 

Hey, thanks man :) I'll need all the encouragement I can get!

I've had a breakthrough today on my compiler. Hopefully I'll have something either tonight or tomorrow that will allude to completing the material editor.

After that I'll look into doing more work on the rendering pipeline. Shadows are a big pain that I'm not looking forward to. I am speaking of, of course, Shadow Maps. After shadows, I'll shoot for a level editor + scripting. The realtime global illumination will come later :)

What do you guys think of having ads in third party maps and sharing the profits with the map authors and possibly the server hosts? ;) If we're going to ad support this, we must do it right!

Author:  sxy [ Tue May 15, 2012 1:54 pm ]
Post subject: 

Sure! Just make a special generic "advertisement" material with standardised dimensions. You can even make a few different types of them: h1xl1/1x2/2x1 landscape/portrait, small/medium/big and leave the positioning (and aligning the material on map geometry) to the map maker. Such "advertisement pack" would either stream to clients during gameplay or only updated itself on connecting to the game server or any kind of official central server.

ps: However, don't expect to get many clients until there is a few thousand regular players ;)

Author:  affine [ Tue May 15, 2012 2:50 pm ]
Post subject: 

Yes, that's exactly what I was thinking ;) it'd be cool to do more dynamic content through in-game streaming. A good example would be a news feed in addition to the server MOTD during the load screen. Pop in an ad there also, and maybe even pong.

If it works, we'll end up drowning in awesome 3rd party content and servers.

There are startup costs that still need to be accounted for. If the team is going to be as small as I think it is (2-3 programmers, 2-3 artists) then we'll probably need a couple thousand to sink on player models (these especially.) I'd rather outsource to the best there than to try and conserve money and use "pretty good" characters that the best weapon artist on the team would make.

The big thing will not be graphics, though. It'll be the community. The ad support helps with this one. Of course, not to say we can't also have good graphics :)

Author:  coroner [ Tue May 15, 2012 3:20 pm ]
Post subject: 

I don't want to dampen the enthusiasm and ambitions but I wan't to avoid misunderstandings of my own position in a potential project:

1) Development of an own engine and tools sets results in a bigger step towards a playable game than there ever was between Q3 and Q3TC or ET and TCE/CQB.

2) Provided stable engine and tools are existing and it seems to converge somewhere, I would take a role of senior consultant. At the moment I can't promise more.

Author:  affine [ Tue May 15, 2012 8:03 pm ]
Post subject: 

I'd almost beg to differ on the step size. There is a wealth of knowledge available for programming various systems, and the dev process can be streamlined with the right practices.

Coroner, just because you're busy does not mean that you cannot be part of the dev process :) I'll honor your opinions regarding my work. For example, I still have yet to settle on a scripting language (albeit I'm 95% sold on Lua)

Author:  affine [ Thu May 17, 2012 2:22 am ]
Post subject: 

I just wrote a powerpoint on spacial indexing. It covers kd-trees, quadtrees, and octrees. The formats are available in ppt, pdf, and jpg.

Here is the link for it: You need to copy/paste this into your address bar. Notice how the very end of the URL isn't hyperlinked :( ... 800D9A!114

I'll probably go with octrees. Tell me what you think, guys! :D

Author:  affine [ Fri May 18, 2012 12:37 am ]
Post subject: 

Another update today.

I've been continuing a few different things that need investigating with my engine. From my research I have decided that I am going to implement octrees, and then continue my culling process through a software rasterizer that draws a c-buffer (c is for cull.)

The software rasterizer is a very harsh representation of "occluders" in the scene. Think of them as a plane you would insert into a wall of a building that you can walk into, or a single large bounding box for a building you cannot walk into. These occluders must be extremely geometry simple. It then goes through and draws each potential mesh that was not rejected from the frustum cull.

Frostbite 2, CryEngine 3, and a few other AAA game engines use this technique. It is exceptionally creative, and super cheap! It takes less than 1ms (according to the slides I found) to do z-culling, and results in obscene performance increases. It's also straightforward to implement.


Author:  sxy [ Fri May 18, 2012 9:16 am ]
Post subject: 

Sounds good. :) I hope it won't be hard to implement.

Author:  affine [ Fri May 18, 2012 5:31 pm ]
Post subject: 

Thanks to Mads Elvheim I now have some code snippets to use :) I can render the z-buffer of a cube to the screen at like 50,000fps. It's ridiculous! This is on a single 3.2ghz core, with lots of programs running the background!

There will be something mappers will need to do in addition, and that is build occlusion geometry. This is really easy and simple. Just like I said above, insert a 1-sided brush (nodraw the other sides) with the "occlusion" shader on it into large walls, and insert large rectangular prisms into buildings you cannot go into.

The artistic budget for a given area will be intense. Seriously, we'll be able to go psycho in a hallway and make it look SUPER great, and it'll run at 60fps on an 8800gt (even less with lower settings.)

Our interior areas will have bigger budgets than Deadspace 2 (they use SO MUCH GEOMETRY!)

Author:  coroner [ Sat May 19, 2012 6:57 am ]
Post subject: 

Hi, good news.
For dense indoor/outdoor geometry like CQB sample map I guess you have to insert a lot of occlusion planes with many holes for windows and doors.
I can live with this.
But since this is something BSP is now doing automatically for us, many poorly build custom maps will be running even worse.
The system you are going for is similar to the one of cryengine 3 on PC, octree with low-resolution software rasterizer to retrieve depth information/occlusion in order to determine what has to be drawn on the GPU. How I understand, you replace the low-res software rendering of the whole scene with simplified occlusion geometry.
In terms of mapping it would be most practical if the CPU occlusion path just takes a the whole brush based static geometry of the map which would ideally just be outer walls, floors and roofs. In classic radiant terms this would mean to mark only little geometry static, the most would be detail and an equivalent to hint or areaportal planes could be used for additional occlusion (e.g. under terain meshes ets.).
From the technical side I still wonder whether such a system would be superior to BSP for classic TC-like environments. Given that VBO are fast for geometry the overdraw caused by BSP might be cheap to achieve.

Author:  affine [ Sat May 19, 2012 5:55 pm ]
Post subject: 

It is much faster, trust me. The reason why it's faster to do it on the CPU is because there's a lag that must be accounted for when doing occlusion queries on the GPU, and retrieving that information. You're only rendering a very basic scene once at a very low resolution, then testing objects against it. The CPU takes <1ms to do this, while the GPU takes well over 30ms in some cases.

For example, my 1920x1080 screen would have a 192x108 c-buffer. It would render all of the occlusion geometry which must be very simple out into this buffer, and the proceed to rasterize all of the potentially drawable objects against it. However, the rasterizer wouldn't actually write out the result. It would test all of the fragments (pixels) of the object while it is being filled, and see if the depth value of that fragment is closer to the camera than the fragments from the occlusion geometry. If it is, then the object is visible!

Many optimizations are made to speed this up. For example, instead of using a full axis-aligned bounding box, you derive a single quad in screen space by taking the mins and maxs of all the vertices of the AABB. The Z-value for the quad is the vertex with the lowest Z value before.

You end up only drawing exactly what you need to (at least 95% of the time.) It's also not very difficult to prepare a map for.

Octrees take only a couple seconds to make, coroner. They're very straightforward. Traversing them takes fractions of milliseconds. They're only a little more expensive than traversing a BSP, but MUCH faster and easier to construct.

Author:  Haraldzz [ Sun May 20, 2012 9:44 am ]
Post subject: 

affine wrote:
50,000fps... on a single 3.2ghz core... look SUPER great... 8800gt...

Dear god, my 5 years old computer will even be able to run the next TC game/mod!

Author:  affine [ Sun May 20, 2012 5:24 pm ]
Post subject: 

Hopefully :) but that's just the occlusion culler. This is to ensure that the least amount of unnecessary models are drawn to the screen.

Page 4 of 7 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group