Ms2dtsPlus issues...

#1 I just yesterday compiled 'Fluffy', the SDK 'orc' mesh into a working player mesh with the SDK default sequences loading just fine[well, some questionable weighting]...I did one with environmental=1 and then one with environmental=0.

Both compiled into functioning shapes, with the enviro mapping=1 giving the shiny blue mapping of the texture...but with enviro=0, everything was fine with the skin.

Don't know what up wit dat?? Fluffy tops out at over 2300 polys in MS3D...and the .png doesn't appear correctly[in ms3d], but that's always happened with the milkfarm.

Run in the v1.4 SDK.
previous compiles worked in v1.3 with TLK.


....say...you say two textures? With one mesh Group? How's that possible in Ms3d, as I thought that only one material per group...that may be a clue.

#2 The second texture slot (assuming that is what your mentioning )on a material list used to be for the alpha channel (gray scale textures) , but is now obsolete because Ms3d now uses 32 bit tga to display transparent textures and if I remember correctly, the second texture slot was supposed to be either disabled
or removed.

I hope that info helped on that part of the subject.

#3 Okay, some clarification is in order.

My mesh is multi-group and the areas affected by the second material are grouped as one unit.

This second texture is not an alpha map, it's a simple self-illuminating texture designed to give a glowing appearance to certain areas of the mesh, so there have been no conventions exceeded that I'm aware of.

I ran a test, creating a simple box in milkshape and exporting through dtsPLus to see if it would load in-game and it did. Guess that tells me that there's either a problem with the mesh itserlf, or the materials used on my vehicle.

Thanks for the input guys.

#4 Hmmm...interesting. I just now downloaded Ms3d v1.7.8, installed it & DTSPlus!.

I compiled Mr.Box[DTSPlus! default rig], with self-illuminating texture it comes with, and it entered the engine just fine, appears self-'lit', and doesn't crash the engine. It however; is but a single mesh object, not a segmented object as you seem to be describing.

This may have to do with the separate mesh objects in the Scene and how perhaps the exporter is handling the multi-Textures and multi-subObjects in the process...?

Also, not certain if the current DTSPlus! operates under Ms3d v1.7.4?? That may be an issue.

#5 Further experimentation is showing me that the dtsPlus exporter is NOT exporting a collision shape even though I am selecting "create bounds" on export.

Here's where it gets really strange - if I create a mesh and name it "collision", not only does it not make it out of milkshape, but the mesh doesn't render in the engine.

If I export without a hand-made collision mesh, it at least shows up alright as a static object... but would the absence of a collision shape crash the engine when used as a player object/ vehicle? Never had this happen before so, despite the ignorance of the question, it's worth asking. =\

At this point I'm absolutely positive that it's not a grouping or texture issue. I can load the mesh in show tool pro and it renders perfectly - but it also shows me that there's no collision mesh. =\

Incidentally, I did upgrade to 1.7.8 even though it had previsouly worked with 1.7.4. I can't figure out what's going on and it's killing me - I can get a working vehicle in their, but I really need the LoD and other features available in dtsPlus!

#6 Okay, Kirby; try this. Let me preface this by saying this was not attempted on a 'vehicle' type shape, this was a simple shape with multiple Collision meshes and one single LOSCol mesh. I got it to work in ShowToolPro[not sure about your engine...;)], but I believe you'll have to work things in this manner:

1. When you 'name' your MeshGroup in Ms3d's TabPanel, remember to append your CollisionType mesh geometry with the '-N', where N= integer between 1/8. This will produce multiple Collision meshes. A vehicle only gets one, so this is moot for a vehicle...

NB: The exporter I believe is to read the meshGroup name Collsion and deal with it's detail level & register it in the export dialog, however; I think that may not be functioning and you'll have to edit the mesh LOD with the export dialog Mesh LODsection, or manually append the detail number[-1/-8; include negative operander] with the TabPanel.

2. Now the tricky bit and it got kinda weird: IYa very weird, still noticing weird stuf..back later
If you like, I can try to get this vehicle a collision mesh appearing..

@ Chris Robertson: I believe/think/speculate/heard? codeBase of the DTS or collision or shapeBase has unlimited collision meshes now, not sure about LOS meshes or how it's handled...at present, DTSPlus! only allows a maximum of 8 of each??

#7 Rex - I will definitely give this a try when I get home this evening.

Off the top of my head I can tell you that I've never appended a negative operand to my collision shapes during export, which could be causing the bulk of my issues.

What's strange is that IIRC the "create bounds" option used to work. I wonder what changed. =\

Thanks for your help - I'll let you know how it turns out. =)

#8 Ya, just went back and got my .CFG right. Either use it or not, I got the meshes to appear. If you don't use the .CFG, multiple Collision meshes get parented weirdly, to like the lowest child of the chain. Once I put LOS* & Col* in Never Export: I got them culled as Nodes, they now appear in the Tree as Skins...eh? don't know if that's bad, but either way, append geometry with negative numbers...

#9 Just a quick question - where can I get some explicit details on setting up a *.cfg?

#10 The DTSPlus! exporter package comes with several example files and excellent documentation. .CFG's are outlined in Default Configuration of the .pdf. Latest copies have me listed in the Credits...! Thanks Chris.

...as to what to place in the Always Export: and Never Export: Never Animate:...I usually do a 'dry' export without a .CFG first...just to see what shows up as Nodes; without a .cfg file, everything gets exported by default. Then I go back and build my lists as to how I want a structure chained together, for animation, etc...that's how I approach things. Get all the Nodes in the base shape, then use Never Animate to isolate the Nodes, I guess you could cull out nodes in the .dsq, but I'm not sure if that's the best way to handle things. The default sequences seem to contain all the Nodes, just not storing any Rotation/Translation values. I think.

Create Bounds radio box keeps the exporter from culling the Root Node and Bounds object from the Scene, it never did anything about Collision meshes; those need to be custom built and named.

#11 Hey Rex - it took some twiddling, but after about half an hour, I got everything to export correctly without a *.cfg. The negative value on the collision mesh was absolutely KEY to getting everything to export correctly.

I'm still puzzled as to why I never encountered this before, but it's proved to be a fruitful excercise as I can see the usefulness of using a /*.cfg and will undoubtedly be using one in the future.

Thanks for your time and your help getting me back on track. =)

#12

Quote:@ Chris Robertson: I believe/think/speculate/heard? codeBase of the DTS or collision or shapeBase has unlimited collision meshes now, not sure about LOS meshes or how it's handled...at present, DTSPlus! only allows a maximum of 8 of each??

I don't think the exporter places any limits on how many collision/LOS meshes can be exported. That limit is in the TGE engine.

Quote:Off the top of my head I can tell you that I've never appended a negative operand to my collision shapes during export, which could be causing the bulk of my issues.

If this was with the stock ms2dts exporter (not ms2dtsplus) this is to be expected. The stock exporter did not support LOD, so there was no need to specify the LOD value for each mesh.

#13 @Chris: So what you are saying is that I can export as many Collision meshes and LOSCol as the engine will handle. That's great; so then in the documents, it has it outlined that Collsion meshes should be -1/8 and the LOSCol meshes are -9/[I forget]. Then this numberingConvention could be altered as with as many meshes as needed and the main qualifier is merely the negative trailing number[numbers NOT being pertinent to collsionType], and the engine keys on the namingConvention of Collision/LOSCol...and the trailing number??

Thanks, Chris, as always...that cleared things up for me...not that I really need that many LOSCol meshes or Collision.