Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Unknown Target on November 07, 2003, 04:35:22 pm
-
I have a 1200+ fighter model, designed specifically for T&L. How do I get it in? Every time I go to the tech room, and select the new ship model, the game crashes. Kazan's PCS chugs down and freezes when I open it (either opening the pof or trying to convert it from a cob), and MODVIEW32 also wont't open it (I get "Error 6008: Too many vertices defined (Vcount>4000), even though there are less than 4000 vertices).
Any help would be appreciated, thanks all ;)
-
You sure you're running the HTL build with the -HTL Command Line option? The Station I was testing yesterday was only around 3,000 polys but it worked fine in FS2.
BTW there is a build of PCS designed for HT&L are you using that or the standard PCS?
-
*Shrugs* I've yet to be able to convert something high poly by myself. I ship off my labor. ;)
-
Umm...where can I find the T&L build of PCS?
And is there a version of the T&L build with the new engine trails, as well as the dynamic lighting and other enhancements?
-
Search for a thread called "What program to convert 10,000 polie ships" It's in there.
-
Hmm. Maybe I should try the full station out rather than just the central core I'm working on. That should take me over the 5,000 poly line.
-
Just ran it with the -htl extension. I got to the techroom, but the game, music included, froze completely. I had to end it. Any ideas?
-
It sounds like a model problem to me
try it with 3.55, and with retail fs2 too (you will have to split the 1200 poly mesh in two parts)
-
Also, I tried the HTL version of PCS to convert. It froze.
PLEASE people, I really need to get this done!
-
PCS is baaad. It doesn't do anything with cobs for me, and Kaz tells me it's my PC's fault. So I can't help. I'd like to get these sorted out as well.
-
I actually remember reading somewhere that PCS will crash while converting on ALL computers.
Oh, yea, update:
I removed the "wings" from my battleship, and left only the main section. Boom, it worked. Sooo...how can I make it work WITH the wings?
-
as I already said, I suppose it is a model problem (if pcs, modelview and fso have problems with it, it is more probable that the problem is in the model itself and not in the individual programs at the same time)
this is partially confirmed by the fact that removing some parts, it works fine: it is possible that those wings have some problems.
To be sure, try to convert ONLY those wings with pcs and cobfs2, and test them in mdview and fso: if they still will crash, you can bet it is a model problem
In this case, the best solution (if you can't find the problem) will be to rebuild them from scratch
-
The wings work seperatly as well.
What else could be the problem? Maybe I'm just cappin out MODVIEW's limits?
If that were the case, then it should still load in the game, right?
Soo...what now?
EDIT: OK, now Kazan's utility can open the pofs, but I get HORRIBLE clipping, and neither FRED2, FRED3.41, FS2 vanilla, FS2_open_e, or FS2_open with HT&L enabled will run it. It crashes as soon as I get to that particular model.
-
for what I can tell you it is a model prob... but I really don't see how a model can get that screwed! what prog you used to model?
-
Originally posted by KARMA
as I already said, I suppose it is a model problem (if pcs, modelview and fso have problems with it, it is more probable that the problem is in the model itself and not in the individual programs at the same time)
While I agree with you I should mention that Modelview has twice completely locked up XP when viewing HT&L models which worked perfectly well in the game. I wonder if ModelView can even cope with the higher poly HT&L models.
-
I'm using Milkshape 3D to model, and Lithunwrap to convert.
And it's not the cobs, truespace sees those just fine.
What could be wrong with the model(s)?
-
to avoid possible conversion problems, try to use 3dexploration instead of lithunwrap.
-
It's payware now, I don't have it.
-
There's a copy of 3dex on the Reci website - version 3.5.1 IIRc, which is the last version which still works after the shareware timesout (albeit limited to one render / 5 model views per seession)
http://www.3dap.com/hlp/hosted/reciprocity/mods_tools.html
-
when converting PCS isn't crashing or locking it's just takeing for freaking ever, just let it run for a few minutes
-
Ok, 3DEX worked with the capital ship, but NOT the fighter. :cofused:
-
So, here's my situation thus far:
MODVIEW WILL open the file that I converted with 3DEX, and it works perfectly. However, it crashes FRED2 and FS2_open (HTL)----I think I'm getting closer with this, but not there yet.
MODVIEW WILL open up the cobs for conversion, however, after I save the files as pofs, I get the same "too many vertices error"
Ideas?
-
in 3dexp, what is the vert count?
btw....
I followed bob's suggestion, and.................
(http://www.3dap.com/hlp/hosted/swfs2/img/snap079.jpg)
:devil:
it just takes ages to convert:)
but I have a question for you Bobbau:
it say 1 group and 40 polygroup. Will HT&L work like if there are 40 subobjects (so with a major slowdown), or will it work with the mesh as only one group?
-
scratch that bob, it was the wrong file :rolleyes:
I forgot to place all the objects into the same layer:)
-
Vert count is 4815 (below the 5000-vert) on the capital ship, but why doesn't it work in FS2?
And the vert count on the fighter is 5220, above the polycount! (thanks, found the problem, but...)
How can I get this converted and working?
-
really don't know, it sound like a model problem as said, but there's nothing I can say w/o sseing the mesh/tesing it, and as you can see I have my own problems too with HT&L:
(http://www.3dap.com/hlp/hosted/swfs2/img/test.jpg)
-
Could I send you the mesh (which fomat?)?
-
as I said, I already have my own problems with an htl model, btw you can give me the cob and I'll give a look at the geometry in truespace
-
I think I know what the problem is, and it's nothing to do with your model (if I'm right)
the max poly tripoints was set too low
-
try this (http://freespace.volitionwatch.com/blackwater/fs2_open.zip)
this is a very interesting model, do tell how well it performs.
when you get to restructureing it for actual use all the subcomponents of the main hull should be in one group, as should all sub components of any other subobject, if you have a version wich has all the corect UV space and textures I might be able to get it set up for you
-
Tried your exe, Bob. It didn't work the first few times, then it worked once, now it isn't working again ( I mean, it crashes when I try to view the models in-game).
-
Originally posted by Bobboau
when converting PCS isn't crashing or locking it's just takeing for freaking ever, just let it run for a few minutes
So, by the program completely ending and dumping me to the desktop, it's really still converting, eh?
-
are you useing the version with the big geometry buffer?
-
Yes.
-
uhmm.. then, uh, yeah.. just, keep waiting...
-
bob, I'm testing now...
unknown target, I'm sorry but with the cob you sent me the only thing you can almost do is to trash it.
I don't know if it is a converting problem, a ms3d prob, or the way you modelled it, but as it is now it is....weird
I think you will never get it to convert with pcs (I haven't even tryed), you may have chances to have it in game if you can convert it with, for example, cob2fs2 (but as you said fso too has problems with your model)
What is causing this mess are the verts.
I was very perplex when I saw a vert count exactly 3 times higher than the pcount, and what I suspected was right: the verts are not connected to each other.
What I mean is that your model is made by around 1500 individual faces, not connected with the neighbor faces, just placed so that the verts of two neighbor faces are sharing the same position, are looking like one single vert, but infact they are not connected in any way.
Since your model is triangulated, for each vert you see there are instead three verts sharing the same position, not connected to each other.
There is no way to fix this in truespace, unless you pick each vert, connect it manually to the verts in the same position, weld the connected verts.
And it would be a bit long to do so 4800 times..........
As far as I know, if you open obj in truespace, you have the same result, and therefore you have to use some converion tools, wich can avoid to have the faces in bits. Don't know if it is the same with ms3d (but you converted with 3dexp, right?)
If it is a conversion problem, well you can fix it just by finding what tools to use
If it is a format/program problem (I mean, if ms3d can work only that way), well you have to disinstall ms3d, try to sell your license, learn how to use TS3.2 or XSI learning or Gmax, wich all are free
If it is you that modelled that way, trash this mesh and start making it again from scratch, with a different strategy
edit->oh and there also were the hierachy wrong, wich could be addressed as possible problem source in game
-
I'll bet I know exactly what's causing this problem too. You put the model through Lithunwrap didn't you? If so try the version from
IP Andrews Page (http://underworld.fortunecity.com/pacman/106/fs2mods/shipcreationguide/).
I had exactly the same problem with Lith once and even though that version claimed to be 0.3 it was different from the one that I linked to.
-
Originally posted by Bobboau
try this (http://freespace.volitionwatch.com/blackwater/fs2_open.zip)
this is a very interesting model, do tell how well it performs.
when you get to restructureing it for actual use all the subcomponents of the main hull should be in one group, as should all sub components of any other subobject, if you have a version wich has all the corect UV space and textures I might be able to get it set up for you
The model is part of a trading with xwaup, they give us this model (and darksaber's already textured ones), and I'll use my textures on this and share them: http://www.hard-light.net/forums/index.php/topic,18539.0.html
So, many thanks for the offer, but it isn't possible now. Btw you were extremely clear about what I have to do to optimize the model for HT&L, getting rid of their incredible limit of around 200polys per subobject :blah:
I made some tests with your exe, here are the results:
ship with around 10400 triangles, d3d8, 640x480, no specular
test1:
non optimized model (40 subojbects, one texture but two materials, according to pcs)
test2:
optimized model (all the subcomponents merged in one one single object)
machine:
very crap system: pII 400, matrox millenium g200 agp,IIRC 12mb,(vodoo2 doesn't work with fso d3d), 256mb ram
test1
htl build:
model is rendered perfectly
average of 16,5/17 fps with one ship, average of 9,5 fps with two
some collision problems, you can fly through (not always) the ship
non htl build:
model rendered perfectly
average of 4/4,5 fps with one ship, the fps counter doesn't go below 4, so I don't know with two ships
some collision problems, but it seemed to me less than with htl build (but it was hard to test with that choppy framerate)
test2
htl build:
model is rendered fine
average of 14 fps with one ship, average of 7,5 fps with two
weird collision problems! you can fly almost completely through the ship
non htl build:
model doesn't work (poly limit I suppose), it return to desktop after launching mission
general notes:
I'm having in both htl/non htl some blue/yellow pixels around some borders of the ship (I suppose it is the gpu, but I never noticed blue/yellow dots on precedent builds)
In both htl and non htl, sometimes a white square of about..uhh..100/200 pixels borders... flashes in the middle of the screen (I suppose it is the gpu, but again I never noticed it in precedent builds)
I'm not sure but it seemed to me that the flythrough was worse in htl build, and it is surely worse in the test2. Is it related to pof (bounding box problem building the model?) or the game? I also tryed to rebuild twice the pofs, with no changes
Even on my crappy system, with a card that don't support HT&L, the htl build is at least 4 times faster than non htl. I could hardly believe such big result. Compliments!
the non optimized model is rendered FASTER than the optimized one, with a 2,5 fps difference in average, wich is a lot considering the %. That's a bit strange bobbau.
My only concern is about collisions.... Before using this model I'll have to modify it a little, adapting it to my textures. This require time, and I'm not sure I want to spend some hours modifying it and unwrapping it, with the risk of a model that will not work properly in game
-
ugh, must've been MS3D. I'll look into it. Thanks Karma!
EDIT: I'm looking at my model geomitry in MS3D, and it was either that or the conversion, because my vertex count is way lower than what was reported in Deep Exploration, and all my vertices show up as one verticy, not 3.
Meh, looks like I'll have to learn that damn Truspace...
-
the odd performance thing may be due to your not haveing an THL capable card
-
yes, I thought something like that.
BTW, do you have any clue about the flythrough problem?
This was happening sometimes in the past, and usually the way to solve this problem was to change converter (cob2fs2 instead of pcs or viceversa), but now this can't obviously be done anymore.
edit->I'll try to split the turretts/engines/radar from the main object, and convert the model as it will be in the final version, to see if the problem persist, but even the other non optimized version was having this kind of problem, so...
-
might be due to the large number of intersections, they arn't a problem for rendering anymore but the BSP tree is still used for colision ditection and haveing polys that go throught each other is going to confuse the hell out of a BSP interpeter no matter how well the tree was constructed, in fact a better BSP compiler may cause these problems to be actualy worse
-
ahrgh!!
ok, well, thanks anyway:)
-
just so you know a BSP tree is a way of organiseing polys based on wich ones are in front of wich, so you can see how a poly that goes through another poly is going to cause problems when you ask wich one is in front
-
well, many thanks for the explanation..
btw this is a problem, and I'll have to solve it...in a way or the other...