Q3Map3 - Discussion and Development

[FRA_ChaosLegion]

Just wanted to give some moral support for ya Silicone_Milk. Great job thus far from what I have read so far. Keep up the great work and It would be real nice to see a decrease in compile times for sure. Plus all other nifty things you might be adding.
Keep it up.

Michael
ShadowZombie

[Silicone_Milk]

Just a heads up:
I'm starting work on a series of articles based on what I've learned of OpenCL so far. The articles will be focusing on how to get started with using OpenCL with C.

I'm also redesigning my portfolio (http://www.siliconemilk.com) to be less.. gritty and more sleek. Also, the underlying code is a mess and highly inflexible in its current state. It's a nightmare to update it with new content as it is right now.

Worry not about the decrease in progress announcements. My focus has temporarily shifted elsewhere but q3map3 will be back to the top of my free-time-priorities once I get my website stuff sorted.

@FRA_ChaosLegion - Thank you

[Silicone_Milk]

Finally got the broken images fixed. I was holding back because I had them in a stupid place and didn't want to edit the links since I'm lazy.

Then I remembered how sexy and eloquent mod_rewrite is and wrote a quick rule that serves up the images fresh from a properly organized folder

I love it when things "just work"

[VolumetricSteve]

I'd also like to give up some serious moral support for this project. I was actually considering trying to build myself a little cuda based quake 3 map compiler because the maps I make are so huge, the wait times on Q3map2 get pretty extreme. I was mostly curious if you were going to remove a lot of the limits built into Q3map2, things like "MAX_SURFACE_DRAW_INDEXES" or maximum brush counts, ect. Of course, realizing that quake3, and ioquake3 have their own limitations, but I get the feeling that Q3map2 hard-coded a lot of code ceilings just because it was easier to code that way. Is there anything to that suspicion or is Q3map2 actually pretty in-tune with what quake 3 can handle?

If you ever accept donations (and if I ever get a steady source of income) this is definitely the kind of thing I'd donate to.

[Silicone_Milk]

I hate to bump this without anything new to add to the progress but I don't want people thinking I just up and left either.

Here's a rundown of what's been happening:
- I started work on a series of OpenCL programming tutorials. The majority of my free time had switched focus to this when I first started them.
- Finals are here! Been busy with school and getting ready for final projects
- Work. I've been getting called in quite a bit and I might be starting a new job on Thursday.

That being said, this project is still alive and kickin'.

[ShadoW_86]

Great! I could really use some new and fresh well optimised qmap compailer . Recently I do some heavy calculations from time to time, feels like it's 2k again - 12h light compile .

[monaster]

*robot chicken style*: It's aliiive!
Keep it going, happy to hear that, Silly!

[VolumetricSteve]

I'd like to reiterate that if this project is taking donations, I'd be happy to shell out the cash (via paypal?) to help with whatever the project needs to enter a releasable state. With a compiler like this, the amount of madness I'll be able to unleash on radiant will reach heights I've never been able to design for before.

Also, what's the possibility of this ever going open-source?

[obsidian]

Q3Map is already open-source, so once he gets the ball rolling he's also obligated to release the source code for his branch.

[Silicone_Milk]

Working on getting a linux build to compile and function before I move any further.

That is all.

EDIT: Linux build now working. Time to get back to opencl-ifying the lighting phase.

[VolumetricSteve]

Hell yeah. Do you currently have it in 32 or 64 bit linux? Also, are you OpenCL-ing the BSP and VIS processes as well? I was thinking about this the other day and it hit me that if those were handled by GPUs/whathave you, the data should really be error checked, as those two phases rely heavily on specific data being in specific places, and one way to do that is to just compile on a Quadro/whatever AMD is offering. Using high-end gaming cards....might do the trick, with the need to recompile on an error. Luckily, Quadros are as low as $150 now. The light process should be fine though, if a lightmap contains a speck or something is off by...a pixel, it won't cause quake 3 to freak out, but bsp and vis errors seem to make it pretty unhappy.

[Silicone_Milk]

It's currently running in x64 but linking against the x86 libraries is a trivial task. I should go ahead and make sure the code compiles and runs correctly on x86 and x64 windows and linux tonight before continuing opencl work.

I'm focusing primarily on the lighting process as *a lot* of the work done in lighting lends itself well to parallel computing (a necessary condition to see a performance gain from gpu number crunching). The lighting phase is also the slowest phase in q3map2 (and only gets slower with higher quality light settings).

[fKd]

[Eraser]

Hell yeah. Do you currently have it in 32 or 64 bit linux? Also, are you OpenCL-ing the BSP and VIS processes as well? I was thinking about this the other day and it hit me that if those were handled by GPUs/whathave you, the data should really be error checked, as those two phases rely heavily on specific data being in specific places, and one way to do that is to just compile on a Quadro/whatever AMD is offering. Using high-end gaming cards....might do the trick, with the need to recompile on an error. Luckily, Quadros are as low as $150 now. The light process should be fine though, if a lightmap contains a speck or something is off by...a pixel, it won't cause quake 3 to freak out, but bsp and vis errors seem to make it pretty unhappy.

But BSP and VIS take a few seconds to compile for most maps, so there's not much to be gained there I think.

[Noruen]

So I do something wrong, because VIS compilling in my map takes more time than high-quality lighting calculations But don't let me bothering you and continue in your porgrammer discussion, this was only quip...

[Eraser]

Weird. I've never had that happen to me.
Are you trying to vis a space map (like q3dm17) or terrain map? I think that doesn't work well. I even remember reading that id Software didn't VIS q3dm17.

[Noruen]

No, very small map (but with a lot of details). Maybe I do something wrong. Maybe if I ever show you some of my source .map file, mappers will kill me in very brutal way for my technique

[DaEngineer]

Do you have a very high structural brush count and lots of nooks and small crannies? Or terrain, as Eraser asked?

To add something to the topic: shortening the time the light stage needs would be a real blessing. Unimaginable what you could do in the time you get back... I have absolutely no knowledge about programming and thus no idea how long it takes to realize anything, but can you tell when we can hold q3map3 in our hands? Waiting has never been my strength

[Noruen]

DaEngineer: No, my building-technique is clear. I'm giving care to structural and detailed brushes, also clipping. so I have no idea where my problem is.

[VolumetricSteve]

I run into a lot of slow VIS compiles myself, but...they're also completely "my fault" but you're right to target lighting first, that REALLY needs the most love of the 3. OpenCL is going to help that a lot, didn't you say you were seeing 7X speed increases already? If you don't want to bother with VIS at all, I may see if I can find a way to work it in whenever you wanna release the source. BSP might be a silly thing to bother adding, but....who knows what kind of insane options someone might want to use that could make it into a long process?

[Noruen]

Maybe it would be possible to create new type of brush like "hint" or "clusterportal" which will not be only offer for q3map how to build vis (hint) or hard cut in level (areaportal) but brush, which will break level like I want.

[VolumetricSteve]

I thought that's what hint brushes did? What do you mean?

[DaEngineer]

He wants total control over portal creation. Instead of q3map creating vis areas automatically AND adding ones with hint brushes, he ONLY wants to make them by hand. This could really be useful, as there are usually portal areas you don't want to have.

[obsidian]

Basically, what you want to do then is this:

Convert all visible brushes to detail, block in some large chunks of caulk, add hint.

Any convex volume of brushes will HAVE to create a new BSP split. You can either prevent vis from using the convex volume for calculations and avoid a split (detail brushes) or you can manually tell it to do a split in some other direction (hint).

[Yatta_Yatta-O_o]

Hello, just a little message to say that, as a mapper (for Wolfenstein:ET) I am very interested in your project and am closely watching progress on this. I there a place to grab a test version ?