T
Milkshape isn’t used anymore. Importers and exporters for it are extremely outdated. Two options are available nowadays:
Either choice covers most modeling-related pipeline aspects.
Yeah that’s probably just a prop (.3db) attached over the head. I haven’t seen any effort to do anything with .dfm in all those years and I haven’t seen any internal development tools being ever released.
Most of the stuff needed to export .dfm are already implemented, it’s just not finished. I’m thinking of having it all somehow tie to 3ds max character animation toolkit, but it is tricky.
I did my tools for 3ds Max because I’m much more familiar with it. Until someone makes equivalent for Blender, but that probably won’t be me. Maxlancer is open source and there are lots of comments to help figure out how Freelancer formats are put together for anyone willing to try.
Piper’s plugins for Milkshape may have been the latest of the bunch but they too haven’t been updated in a very long time, and like tools from that era they have plenty bugs, mostly from insufficient information about data structures in formats.
Large .sur size is indicative of a bad export: some tools “break” concave meshes into double-sided triangle hull per mesh face. Accumulative BVH offset drift bug in obj2sur only exacerbates the issue and results in unstable hitbox. Freelancer collision physics are fine as long as you feed it correctly pre-calculated and well optimized data.
This error indicates some triangle vertices are outside of vertex buffer, in game this may result in corrupted graphics as it will blindly read memory outside and interpret it as attribute data. This is pretty bad.
I would suggest importing source .obj into 3ds max and assembling model there (including hardpoints and hitboxes), done right the result will be 3db (or cmp for multipart) with sur file.
Meanwhile here’s your model (in .3db) with a nice hitbox and a little extra.
p.s. Hah, just realized this was a gravedig. Nicely played, kids )
The thing is I went the path of creating perfectly convex shapes prior using obj2sur and maxlancer
Since the days of the milkshape sur exporter I avoided concave shapes.
Obj2sur in the latest version even has the “yes I am sure that everythign is 100% convex”-option which I of course tried (without different results, sure the sur is smaller because there is no splicing but the lag remains)
I no longer use obj2sur so not much I can say there.
The station models are relative complex, with negative space for docking bays etc.
To ensure everything is convex I created a simplified version of the stations which I broke down into groups of convex shapes to mimic the overall shape. That was the adviced method ever since we were able to create own surs.
When you make a hitbox the result is always going to be an approximation and the objective is to make a rough shape of the object using fewest possible and least geometrically complex convex hulls. Generally speaking the less triangles and individual hulls the better it is for performance. Unlike rendering the game physics can’t process complex geometry, it’s all done in CPU and in case of Freelancer it happens in main thread as well. Cut the corners where you can, if you can cut the third of hulls and/or triangles - it’s worth doing in a long run. From my observation the game has some kind of internal time limits and if exceeded the game will discard some hulls in the model from further calculations.
Since I observed these issues with obj2sur I tried to use maxlancer and its sur builder. But even there I can observe these lag issues.
I tested multiple export methods.
In one method I imported the simplified sur model with convex geometry groups from a different program and then exported it with maxlancer
In a different try I allowed the sur builder to generate the convex hull shapes, then exported the model with the sur.
There seem to be multiple export options in maxlancer… I tested them all.
In every case I am able to reproduce the lag issue by bumping my ship into the station often enough. Depending on the method used it takes a bit longer to break the game.
I am not sure what I am overlooking right now.
The use of maxlancer was adviced to me by somebody helping me with some refresh of older 3d models but even there I noticed that his models which purely were done with the surface builder can trigger the lag issue.
Without looking at problematic models you refer to I can’t say for sure what might be the cause.
The BVH tree you mentioned (correct me if I am wrong) is the color coded stuff you get when enabling the hierarchy option on the sur import in maxlancer, right?
BVH (Boundary Volume Hierarchy) is a pre-calculated BSP-like tree for collection of hulls in a single part and is an element of optimization to perform faster lookups in collision detection code. In maxlancer there’s a debug option in import dialog to display and color code BVH nodes. White/grey is normal, yellow means hull geometry is outside node and red means node hull is completely outside node boundary. Yellow isn’t always a sign of problem, if geometry barely sticks out that’s fine. Red however means its hull is most likely not going to work. Most problems with .sur generated by obj2sur working partially were related to it having errors in BVH calculation (nodes would often have erroneous offset by X axis making boundary either partially covering hull or entirely missing it). My post here explains it further.
I discussed this possibility as error source with 2 other modders a few weeks ago.
If so, is there a way to fix this?
Hard to say because since in disco we pretty much remade and re-exported all hitboxes. I have not heard of lags specific to collisions since then.
Even the surs generated by the surface builder of maxlancer have these yellow and red boxes sometimes. I am not sure how to avoid that. The one post I was able to find about that was not so clear to us.
Sure, yellow boxes can sometimes occur because boundary parameters are stored in .sur with reduced bit depth, so there’s loss of accuracy, but the game accounts for that and it should not be a problem if hull generally fits within its node box. In theory maxlancer should not produce those “red nodes” at all. If somehow it does that then fill a bug report and provide assets where it happens - I’ll look into it. Meshes produced by surface builder are not intended to be manipulated afterwards (other than deleting if you didn’t like the result and want to redo).
I’d reckon performance issue you’re having is caused by obj2sur breaking down concave hulls into triangle hulls, which you should avoid at all costs. If you have hitbox comprised of hundreds of hulls then it’s obviously a very bad situation. Individual hulls in a hitbox are expected to be convex and that’s just how it should be. Lastly obj2sur often generates incorrect BVH tree.
Just use surface builder in maxlancer for 3ds max to create hitboxes.
Yeah it’s overzealous AV having false positives, been a huge headache for me to solve so far, seems I’ll have to do installer in different software and code signing is a mess. There’s no malicious code in it, in fact there are no executable installed at all, just a bunch of maxscript files, shaders and png icons.
This model has arbitrarily bloated number of VMeshGroups in mesh for no reason whatsoever. It’s not engine job to resort and merge groups, it is exporter job to produce sane result by combining face groups matching material within each LOD of each compound part.
I’ve just re-exported it in Maxlancer which resulted in only 6 VMeshGroups. 6 draw calls is all it takes and all it should have ever been in the first place. There never was any excuse to have any more than that.
It’s just a very badly exported model. VMeshGroup of same material reference are expected to be pre-merged within block range of single VMeshRef. There’s zero benefit of fragmenting it.
This is clearly a very bad attempt to get around the fact milkshape exporter can’t properly export vertex normals (and exporter being dumb enough not to merge mesh elements by materials).
All in all that fragmentation had led to 6200+ draw calls and that’s the cause of such low FPS. Model doesn’t exceed any buffer limits nor is anywhere close to, it’s just a very bad export case.
That’s kinda stupid. For a revolute part (which quarters_lod1 is) the values that go there are pairs of timestamp (in seconds) and rotation angle (in radians). The ones you list are going to create partial spin back and forth rather than continious one.
Assuming you want to do full 360 spin in 10 seconds the solution is:
0.0 <- Frame 1 timestamp: 0 seconds
0.0 <- Frame 1 value: 0 degrees
5.0 <- Frame 2 timestamp: 5 seconds
3.14159 <- Frame 2 value: 180 degrees
5.0 <- Frame 3 timestamp: 5 seconds
-3.14159 <- Frame 3 value: -180 degrees
10.0 <- Frame 4 timestamp: 10 seconds
0.0 <- Frame 4 value: 0 degrees
Notice the doubled keyframe at half duration, a flip occurs there to continue rotation into a loop.
Flip signs at values of mid-keyframes if you want to rotate the other direction. Naturally your Rev part must have min/max angles set to -360 and 360 degrees respectively.
Quite frankly I just don’t see what’s wrong there, probably because whatever is supposed to be incorrect is just too far and youtube quality makes it all kinda hard to spot anyway.
Either way it’s all about how map keyframes are set and whether they are looped or not. Some vanilla models have that and for full 360 rotation they have to make a quick jump as maximum rotation between two keyframes is 180 degrees. This jump can become noticable if there’s time delta between its keyframes.
How animation plays out depends on several factors. If animation script contains maps for more than one part and each map has different durations the animation will go out of sync as each part will have its animation looped independently. Type of looping is defined by event_flags property (restart, reverse, ping-pong, etc).
There is a simpler fix for lights textures, you just need a model to embed texture used by those light sprites (matching name too) and push it into scene so it’ll load the resources and display those sprites.
Regarding paths I’d normally just make them in 3Ds MAX. But there isn’t a readily available solution I’m afraid, so it’s not like you can install it, make paths and grab em from there. For my own uses I’ve made a script to export spline knots and capture rotation of a dummy object to THN path key points.
Glad to be of help. Just keep in mind while most information here is correct a few things aren’t, I simply never got around to correct them or to continue writing it.
Monitor is meta-object representing your viewport, your screen to put it simple. Switching between cameras is event of SET_CAMERA. You should have only one monitor object in scene.
Pretty much every color there is going to be RGB, however THN is inconsistent when it comes type of values: integers ranging from 0 to 255 or normalized floats from 0.0 to 1.0. Some properties expect integer, others expect float.
Regarding lights it’s just a case of textures not loaded for some reason, so it defaults to plain white color which is then tinted to whatever sprite had for diffuse color.
Here is unfinished doc I was writing on THN stuff. If you want to continue from where I left off feel free to request writing rights.
TBN data could be put and spread across uv mapping vectors in VMeshData. FL materials don’t use more than two uv maps, so six more channels as defined by FVF are free for the taking. Some quantization techniques could be employed to compress into fewer bits. Though if the cost of generating them on the fly isn’t hitting performance it might not be as useful.
A quick update. It is still in development.
Character animations. I was really curious about that given complete lack of .dfm tools. Ichiru helped to get initial mesh, after that I began digging into bone structures and finally animations which proved to be not so simple. Currently I only have importing functionality, but once most things there are put together exporting deformable models will be relatively simple to do.
Most work regarding rigid models is complete. CMP and 3DB are supported. Hitboxes (.sur) can be imported and exported as well, as closely as I can to match vanilla behavior (like parent parts duplicating hulls from fixed descendants in parent coordsys).
Materials use custom DirectX shaders, can be imported and exported (either separately or embedded into model files). At the moment only a few common types are implemented: various Dc* types, nebula, btdetailmaterial and nomadmaterial. Textures are automatically decompressed into Targa images and specific filename patterns can be used to indicate what format texture will be exported to when put into .mat file or embedded into model (requires Nvidia Texture Tools installed).
HUD wireframes can be created either by line objects with knots snapped to mesh vertices or by extracting visible edges (in 3Ds max Editable meshes have manual edge visibility).
A few additional tools were made to have starscape modeling much easier.
Getting pretty close.
