it's been a long long time since i was converting hl2 format models...

i believe there's a 3dsmax plugin that imports SMD files directly.

http://www.chaosincarnate.net/cannonfodder/cftools.htm
get mdldecompiler here.

this lets you decompile the mdl file into all the seperate pieces to get the smd, which, afaik, is just the mesh with vertex weighting.

then go here:
http://www.wunderboy.org/sourceapps.php
and pick up the 3dsmax smd importer to directly import the mesh into 3dsmax. this should preserve vertex weighting. 

for the links, necros!
I didn't realize it were hl2 models as I only came to HalfLife1.

I earlier overcame to the stunning effect when importing an enforcer it meshed up the bullit inside its gun, so I didn't understand were my extra triangle was left after exporting.

I only have 3D Studio MAX R3.
I hope the converters can handle this old version.
I could install Milkshape to get the bones preserved as modelling can get messed up when I start adding them myself. 

Ninety-two percent.
Oh, woes! Will you ever stop?
Space maps suck to VIS. 

You're into the slowest part of the process.

Really looking forward to this map, and won't be the only one - if its any consolation. 

that map i posted about a couple of weeks ago... estimating 1351 hours, and that's *with* willem's multicore fix. -_-

i suspect i will have to rework it. :P 

TreeQBSP v2.05 -- Modified by Bengt Jardrup
Mac port by Willem
Input file: leamondetest1.map
Output file: leamondetest1.bsp
*** WARNING 03: Line 45756: Brush with duplicate plane
[a bunch of duplicate plane errors removed]
Title: "Lea Monde"
31430 faces
5229 brushes
1023 entities
117 unique texnames
3703 texinfo
*** ERROR 37: Failure seeking to 1694052352 in file rt_gnosis_q1.wad
29 warnings
Elapsed time : 0:01
Peak memory used : 5.1 MB

So as you can see, qbsp is spitting out this bizarre error as it is loading my .wad files. I have 4 wad files I want to use, which are all in the same directory as qbsp. My wadfiles are fine, that is, they loaded with no errors into a wad editor. The above "failure seeking" error is generated when only one or two of my wads is specified in worldspawn. The number it fails to seek to varies with the number and order of wads listed in the worldspawn's "wad" key; sometimes it has been negative, but it is not random - for any given order and number of wads, the number spit out will be the same. If all four wads are listed, I get this:

qbsp(3538) malloc: *** vm_allocate(size=2690650112) failed (error code=3)
qbsp(3538) malloc: *** error: can't allocate region
qbsp(3538) malloc: *** set a breakpoint in szone_error to debug

If I am reading that vm_allocate() right, it is trying to allocate 2.6 gigabytes of memory, which I don't have. My machine has 1.5GB of physical RAM, and I got this error with 1.1GB available. I'd have thought that OS X's virtual memory management would have taken up the slack, but apparently not. Also, I was unable to reproduce the out of memory error just now, which confuses me further, but reinforces my intuition that it's a cover for something else going on. The failure seeking error is persistent however.

Oh, and the weirdest part is that if I remove the "wad" key from worldspawn entirely, the errors go away and the qbsp finishes. But I don't think it's going to look very pretty without textures. The map itself is pretty big, ~5200 brushes, but that ought not to matter because I'm getting these errors before the meat of the qbsp process even starts.

Lastly, if I ever do get this thing compiled, it has a painful lack of visblocking. You guys are scaring me. 

this is sort of a long shot, but it's all i can think of.

looking at the bsp info above, 117 unique texnames meaning 117 unique textures. this is a lot and i know there's a limit to how many textures can be stored (or is it a limit on how much memory can be used in textures?)
and the limit may only been in the engine itself, not the compiler, it's just that when you said that removing the wad key (and hence not loading any textures) makes the problem go away is what made me think of it.

try making a test map and replacing most (or all?) of the textures with a single one and see if that does anything... 

The number of textures isn't the problem here (there have been maps with twice as many). There seems to be something wrong with the WADs, some that your editor doesn't mind but QBSP chokes on. Try merging them in TexMex or at least save each of them to a new filename in case there're some faulty bits somewhere. 

ijed: Just as any new map is appreciated and looked forward to. Keeping you informed about the process is actually a double-edged affair, since it kind of renders me as a fool for going through such a hassle for so little gain, both in terms of VIS results and the quality of the map - which is not to say it sucks, but it got out of proportion some 500 hours ago. :D

necros: Keep in mind the time esimations don't stay constant throughout the whole process. If it says 1300 hours in the beginning, you can bet it'll go up dramatically at a later point and especially towards the end. Better add a digit. 

yep. i'm currently running a test with vis -level 1.
if that's enough to keep things smooth, i can stand not having super accurate vis calculations.

there's something wierd though, because i seem to be getting strange behaviour with the timer.
elapsed time is incorrect saying 34 minutes when it has been running for over 2 hours...
the estimate at level 1 is only 3 hours, but if the timer isn't working, than likely nothing it's outputting is correct... i'll see what it's like tomorow, i suppose... 

But this is a big negke space map. 

maybe the elapsed time readout is based on actual cpu tics used for vis, not real-world elapsed time? 

i doubt it because that doesn't really make any sense for aguire to code it that way. besides, i've used his vis for lots of maps and never had anything weird like that happen.

trying again with -level 2 and it seems to be working properly now. 

I put one texture on all brushes in the map, "wad" = "knave.wad" in worldspawn, and still this:

*** ERROR 37: Failure seeking to 471762432 in file knave.wad

I imported the whole map into a new file, and still the same. I even tried on a completely different map. If there are no wadfiles in worldspawn, it will compile. If there are valid wadfiles specified, qbsp will fail. Either there is something really fucked on my end, or there is a problem with the Mac port. Sorry to bother you all, I'm gonna go bawww at Willem now. 

If that WAD file is loading into your editor correctly then there's no reason it shouldn't work in QBSP. Weird. 

Which editor are you using ? 

it's gtkradiant 1.4 on mac os x 10.4. I convert the map file to q1 format with sleepy's java map converter. I would be using Willem's excellent Toetag, but it rendered my stupidly big map at molasses speeds on this old hardware.

In qbsp's source code, warnerr.h, I see that there is an "errSeekFailure" which is obviously what I'm getting. When and where would this be called?

I've tried several wads, most straight from quaddicted and a few I've assembled myself, all giving the same error.

Actually, I just had the horrifying thought that it could be failing to seek because my hard drive is dying. Yikes. Though I haven't noticed any other similar problems. 

Oh, I didn't realize it was a Mac port. In this case you, can put all the blame on Willum. Is there any other compatible QBSP you could try, perhaps with a Windows emulator? Doesn't MacRadiant save to .map or why do you have to use that converter? 

Indeed, the editor is not relevant, however for some reason, sometimes during .map generation, it can generate weird stuff.... anyway, the fact it is a Mac porting is certainely the issue.
You may should try with TxQBSP instead, or move to a PC... :( 

The fact that it's a Mac port should actually have very little to do with it. I use that version of it all the time and it works fine for me. I can't imagine what the issue is here...

Definitely try another version of QBSP and see what happens. If it's my fault, that's fine, I'll fix it - but I'm having a hard time buying it at this point in time. :P 

 

Grahf

Email me the MAP file and the WAD you're using (preferably something reasonably small) and I'll try compiling it myself. Should be easy to track down what's going on... 

 

Ahh OK, grahf has a PowerPC machine. I don't believe these tools are set up for big/little endian swapping. I believe the tools are currently Intel only.

I'll put that on my task list. :) 

I had a feeling that might be the cause of my problems. Thanks for looking into it anyways.