rmf 2 map problems
by Tobias Reich · in Artist Corner · 07/23/2002 (8:26 am) · 7 replies
Hi there
I've rencently made a prefab for our project in Worldcraft, but after compiling it to dif (or just exporting it as .map file in WC itself) all vertices are randomly move around, so the brushes look broken up and no longer ift to each other. This only happens to vertices which are connected by a line that is not parallel to a coordiate axis.
Anyone got a solution for this?
I've rencently made a prefab for our project in Worldcraft, but after compiling it to dif (or just exporting it as .map file in WC itself) all vertices are randomly move around, so the brushes look broken up and no longer ift to each other. This only happens to vertices which are connected by a line that is not parallel to a coordiate axis.
Anyone got a solution for this?
#2
I did that, snap to grid was on all the time. I also placed all manipulated vertices on the grid.
And the moved vertices in the map file are not placed on the grid.
Maybe it helps if you can see an image of the prefab: www.vectorbased.net/blackbox/media.aspThe shot is taken from further away so you can barely see the errors, they are at the cables and the crystals.
07/23/2002 (3:17 pm)
Hmmm no,I did that, snap to grid was on all the time. I also placed all manipulated vertices on the grid.
And the moved vertices in the map file are not placed on the grid.
Maybe it helps if you can see an image of the prefab: www.vectorbased.net/blackbox/media.aspThe shot is taken from further away so you can barely see the errors, they are at the cables and the crystals.
#3
07/23/2002 (3:39 pm)
Then maybe some of the solids are invald. HL map format doesn't support concave primitives, so after exporting from rmf, open .map and double check your geometry. rmf is a more open format so Hammer doesn't report every geometry error you might encounter in .map.
#4
this might sound stupit but i use the texture lock button in WC and never had any problems with textures sliding of ther cracker but this was ony with halflife
07/24/2002 (2:01 am)
looks good that screen shot this might sound stupit but i use the texture lock button in WC and never had any problems with textures sliding of ther cracker but this was ony with halflife
#5
And htere are no error messages, when I check the map file.I
07/24/2002 (2:32 am)
Ok, I've checked the prefab for invalid brushes and after I auto-fixed them I also get the broken up brushes in the rmf format. But it reports no error for the crystal's brushes and these still get messed up in the map format.And htere are no error messages, when I check the map file.I
#6
07/24/2002 (3:31 am)
You'll probably need to go to each seperate error and fix by hand. I believe WC allows you to do this without auto-fixing them.
#7
Another note...some shapes are impossible with WC...period. If you try to create a .dif with too many oddly angled surfaces, it simply won't compile properley, regardless of the size. The only solution in these cases it to create the object with tetrahedrons [the simplest brush possible]. This will usually require you to use a seperate collision mesh [by defining collision brushes] to avoid serious slowdown when collision detection is being perform [especially with smaller objects]. Currently once you use collision brushes, any non-collision brush becomes passable, though they may decide to 'fix' this...in which case you'd probably be SOL in the above scenario.
07/24/2002 (1:23 pm)
Also, note that WC doesn't necessarily find all invalid brushes...it is possible that very small errors are not being identified. Make sure you 'do the math' on every face of your interior...if you're seeing cracks or vertices that are being moved, it's because all the points on a face are not aligned on the same plane.Another note...some shapes are impossible with WC...period. If you try to create a .dif with too many oddly angled surfaces, it simply won't compile properley, regardless of the size. The only solution in these cases it to create the object with tetrahedrons [the simplest brush possible]. This will usually require you to use a seperate collision mesh [by defining collision brushes] to avoid serious slowdown when collision detection is being perform [especially with smaller objects]. Currently once you use collision brushes, any non-collision brush becomes passable, though they may decide to 'fix' this...in which case you'd probably be SOL in the above scenario.
slipi