It works, but if I look at a face and not all of its verticies are visible in the window then the projection screws up, aligning the last UV coordinate to any other visible vert.

That's a bad description. Basically the UV's are all fucked up. That's better.

And Orl, there will be such a fix for your card, AFAIK Nvidia is much better supported, although to be honest I didn't know there was a WC problem.

What the DLL does is disable stuff, you'll notice there wasn't one there beforehand. WC checks if one exists and if so uses it in favour of the onboard library.

Does anyone have the knowledge + inclination to make one that forces software mode on? In WC1.6a there was an option for this :P 

Maybe I don't understand the problem with UV's that you described, but try to enable Texture Filtering in 3d options window. After enabling this option the textures look ok for me. 

If it works my mapping time will double. 

And Orl, there will be such a fix for your card, AFAIK Nvidia is much better supported, although to be honest I didn't know there was a WC problem.

Unfortunately, I very highly doubt there will be a fix. Basically the problem is, using any Nvidia drivers after version 182.50 in Worldcraft 1.6a in software mode, the 3D view is completely garbled, making it impossible to see anything.

And yet, even the older Worldcraft 1.1a's 3D view works perfectly fine with the latest Nvidia drivers... strange.

For whats its worth, I'm running Vista SP2 with an 8800gt. 

That works; turning off filter textures. Can't believe after pissing about with all those different (non) solutions I missed that option.

So the dll + filter off solves it for me - thanks!

Orl, have you tried 3.3? It might sound like a ballache to switch, but the texture lock alone makes it worth it. The renderer changed a fair bit (which is why I and others have had problems) but maybe its worth a try so you can map. 

textures and wc 3.3

does anyone else have problems converting texture files (not just because of overly large textures) with Bakers wad converter?

I think RT23 had some issues with that too - or maybe he helped me with mine... It's all foggy... ...what year is this? 

But the wads you wanted were weird

I never had that problem until I tried to convert that WAD which you were saying you couldnt manage.

Cant remember if I had to use texmex or wally as well as the supplied util. Its all on this thread somewhere, lol!

Most textures convert fine, it would seem to be some wads which dont (!) 

I hope somebody here can help me.I have make some small maps and trying different stuff they compile right and start. But the lighting isn't just right... I don't know what's wrong. I downloaded the original quake one maps in a .map format and there is the same problem.

The map E1M1.bsp for example. Some corners and the first double door left is way to black. On the door you can't even see the textures....
Many places are pretty same as in the game but when i started the original map in the Pak0.pak not through Worldcraft everthings is normal.


I use fitzquake085.exe for the game and the Quakeadapter tools for compiling and testing.

What tha hell am i doing wrong ???
Please reply cause i want to make a real map and not test maps anymore, and that's the only problem that prevents me from getting starting.

sorry for bad english i am from germany! 

Open the .map file in a text editor, find some of the light entities and copy the text and post it here.

or upload one of your map files and ill take a look if you like.

Also take a screenshot of the Run Map window you get in Worldcraft when you press F9 "to run the map" and another screenshot of the "tools -> options -> Build Programs" window.
Seeing those might help too..... 

Some corners and the first double door left is way to black

Maybe you use the wrong light options?
With Aguier's compilers you should have good results with let's say:
light.exe -dist 0.6 -range 0.6 -light 15 -soft

http://user.tninet.se/~xir870k/ 

the converter doesn't convert any of my wads. I could try to convert id.wad and it wouldn't convert.

actually...

"Error creating HLWAD: c:\program files\worldcraft\textures\id_base.hlwad ... details ...No log exists."

So, I guess I'll have to convert them with Texmex? I don't really even know how to do that - anyone have links to more info on this?

Oh, and good luck bobbbybob - i'm sure you'll figure it out if you follow Ricky's advice. 

I dont really understand how the tool was made.
I mean what is .NET framework, cause I dont know if the tool uses anything like that or even anything different or what-haveyou.
Its pretty weird that it dont work for you.
I have loads of hlwads on my HDD.

http://www.mediafire.com/imageview.php?quickkey=rjm5lvzf3i3

If you would like me to mail you any of them I will do happily :D 

I get the same error. No solution yet.

BobbbyBob, post a screenshot - map data could help, but it sounds like you've got something badly configured somewhere in WC.

The screenshot will clarify the problem. 

"Error creating HLWAD: c:\program files\worldcraft\textures\id_base ...""

Are either of you using Vista or Windows 7?

The qconverge command line utility expects to be able to write to the folder it is in.

And come to think of it, the QuakeAdapter expects to be able to create a .bat file to execute.

I know with Vista the idea of having write-access to any given place isn't exactly a certainty. 

and converting txtures via texmex, don't have a texture problems at all,

maybe it's time to switch to hammer editor to you guys? ;) 

Vista. It occurred to me that the security crap is most likely blocking the thing from working. Turning it off spams error messages so I was about to try converting in a 'non-secure' (aka 'non-fucked') folder last night but got caught up in something else. 

Might be helpful to some for a better understanding why things sometimes take so long.

Courtesy of BJP:

OK, this is just my interpretation of how vis works, it may not be correct.

Apart from its normal bsp building from the map, qbsp also generates the portal (prt) file. This is done by dividing all the empty volumes (player space) in the map into smaller pieces, called vis leafs. The more complex solid architecture, the more leafs you get.

These leafs are just convex polyhedrons (like brushes) with at least four sides (the simplest pyramid). All the sides of the leafs are the vis portals ("doors between leafs"), but I'm not sure if the sides against the solids are also counted or it's just the sides between the leafs.

When calculating visibility, all these leafs have to be checked against each other to determine which ones that are visible from a certain leaf through all of its portals. It's assumed that the player can be in any of the leafs (no matter how small they are) and look in any direction.

To make things worse, visibility is checked twice for each portal, one in each direction (back and forth). I don't know why this is.

It should be noted that this "leaf visibility" calculation is a simplified variant of the more realistic point-to-point visibility, which would probably take even longer time since the position granularity is higher. The leaf visibility method also increases engine overdraw, i.e. it'll have to render stuff even if it's actually occluded, thereby increasing r_speeds.

Since all leafs have to be checked against each other, this is a variant of [at least] an "n x n" (n being # portals) problem, which will scale very badly as n grows. This is the main reason why more complex maps take so extremely long to fullvis.

In fastvis, vis first makes some simple analysis and determines which leafs that can be trivially rejected as being invisible and all others are marked as "potentially visible", i.e. need more calculations using fullvis. If you just run a fastvis, all the potentially visible leafs will be rendered by the engine as visible, slowing things down. When building a map to be fullvis-time-effective, it's probably vital that fastvis can trivially reject as much as possible.

In fullvis, vis goes on to the significantly more complex algorithm, where it "flows" through all the potentially visible paths, checking if there's a way through. This work is divided so the simpler paths are calculated first, since they will probably be used in the more convoluted paths later. This is the main reason why vis slows down so much while running, it has left all the heavy parts for later.

The division also lets vis manage the multithreaded aspect by having several threads doing different paths (but still the simpler ones first). I can't say though if it's guaranteed that all simpler paths have been done by all threads when the more complex ones are about to begin. In my version (and most others), that's a non-issue, since the paths are all done sequentially by one thread in the right order.

With increasing # leafs and portals (which you can read at the beginning of the prt file), you can probably realize that the amount of calculations grows very quickly. 100 portals will generate 40,000 "work items", for 1,000 portals it'll be 4,000,000, 10,000 portals is 400,000,000 and so on. I don't want to think about 100,000 portals ... 

Hi thanks for the answers.
Ricky, here are the screenshots and compile logs.
http://rapidshare.com/files/302918736/quake_screenshots.zip

With light.exe -dist 0.6 -range 0.6 -light 15 -soft it's like no rad / fullbright.

But I didnt' know that you can configure the light.exe thanks for that info MadDog. Maybe someone know how to set my light settings right.If not, i will put some more light enities and a higher brightness value in my maps. This will work i think...

The lighting in the compiled originals quake maps have irritated me. 

Well I need that actual light entity information, you have sent me the information for somebrushes with a light texture on them.
The light entities will be at the bottom of the document (the .map file that is) and will look like:

{
"classname" "light"
"light" "200"
}

As for the command line options well I would use (for a map the size you have) -extra4 and nothing else.

But yeah you can use a "wait" key in your entities to make the light spread out further or be more concentrated.

A wait of >1 will make the light more concentrated, i.e.

{
"classname" "light"
"light" "400"
"wait" "2.5"
"origin" "blah, blah, blah"
}

And a wait of <1 will make it go further, i.e.

{
"classname" "light"
"light" "200"
"wait" "0.3"
"origin" "blah, blah, blah"
}

You can also use "delay", but Im no expert on that one. I seem to remember delay of 2 being nice effect. 

That's a door that's fullblack? If it a door or other entity (func_wall or whatever) then it fullblack because the origin is outside of the world.

This means that it doesn't start inside the vis'd (lit) space.

Select it, the red X in the centre is the origin - if that's outside of the lit space (inside a wall, like yours seems to be) then the whole thing won't be lit at all. So make a recess for it to fit into or make it smaller so the origin is inside the world.

It's worth remembering that although entities look like they're normally brushwork in many ways they behave like point entities.

In other words, they only care about where their origin is when it comes to light and vis. 

Those were missing from the above post.

Also 'brush entities' as opposed to 'entities'.

Having a baby is the greatest thing in the world, but your head is all over the place for lack of sleep. 

Its an optimisation (AFAIK) of AguirRe's that the compilers don't light all brush entities no matter where they are, like id's did.

Definately a plus, but also shows another b0rky map feature common in the originals.

Mind you, very easy to be aloof ten years+ after the fact. 

Thanks for the help! The last post is what i wanted to know. I found it weird that the original quake maps had different lighting when starting in Worldcraft. Thought it was a problem in my Worldcraft configuration or something.But that explains it all.

And i am not sure if you notice that the in_game_screenshot.JPG was a screenshot of the original E1M1.bsp not mine small testing maps.

Anyway Big thanks! 

That's why I said that AguirRe (who's compilers come bundled with the wc3.3 adapter) made optimisations that id didn't.

If you used their compilers it'd work without showing the door black but take alot longer. and run very slightly slower in game I think as well. 

you lucky father and happy mother.

apparently the same goes for a good map:
Having a map is the greatest thing in the world, but your head is all over the place for lack of exit.