XeNTaX

revelation wrote:Just a minor update. Texture format should work for ps3 version now.

Is this the Last noeisis plugin update for red dead redemption?

Hello Mr.Adults, my question is if possible support Nif 20.2.1.7 in Noesis, when I try load them I got erro and won't load, the game is:

Game: Looney Tunes ACME Arsenal
Platafform: WII, XBOX360,PS2
Engine: Gamebryo

http://puu.sh/i7YmR.zip

PS: if you can grateful for support them, many thanks buddy.

Is there any way to convert back to GMO exported GMO file?

Hello, Mr Adults and all users of Noesis! Couldn't anybody here add support (write a script) for Lord of the Rings War in the North .dat files or Lord in the Rings Conquest .dat files? I cannot find any tool able to convert these 2 types of DAT. Here are some samples of such files from both games -
LOTR War in the North Meshes (contains meshes of objects) - http://nekaka.com/d/hU6Af4DgFx
LOTR War in the North Textures (possibly dxt or dds) - http://nekaka.com/d/9WOoF21gnQ

LOTR Conquest - http://nekaka.com/d/97eHKu5V5x
This archive contains samples of several filetypes which I found after unpacking Rivendell.BIN archive (DAT, TXT, VAP,CWB,DC5 etc). I am not sure but I suspect all meshes packed in dat files.
I would be very grateful for any help and support for these games.

I happened to notice today that there are a whole lot of importers electing not to do triangle bucket sorting when using the RPG interface. This is usually not the thing to do. So there's a new build up that will let you use -rpgforcesort to force the importer to use the sort. This is probably the right thing to do globally, but I don't like throwing things in the house of cards, so consider adding it to "Data viewer->Persistent settings->Other->Default preview commands" as desired. It will almost always reduce your mesh count for importers with multiple commits per material.

Been working on an importer, and now I wonder - how to properly represent a concept of a dummy object in Noesis?

A dummy in my case is represented by two vertors in a local coordinate system, in addition to global coordinates with scale and rotation vectors: It seems like it's a bounding box.

You can do whatever you want pretty much. A few likely options off the top of my head would be making it a custom data structure in a named user vertex data stream (if you want to be able to do something with it in an exporter by looking that stream up by name), making a bone to represent it, or making a dummy mesh to represent it. Because named user vertex streams will get out of sync if you export it to something like FBX and modify it, I'd probably instead go with making a dummy mesh, and just give it a material that doesn't render as well as a dummy triangle. Encode translation/rotation/scale into the geometry via a few verts, and optionally represent the box with a couple more verts. This way, as long as you give the mesh a reliable naming convention, a corresponding exporter could scan the scene for those meshes and convert them back into the relevant data.

Mesh data is the only thing guaranteed to survive to all model export targets. Material properties are supported by some exporters but to varying degrees, as are bones. The FBX exporter has a sidecar format that can also support user vertex data streams, but as mentioned, that will get out of sync with the actual geometry if it's modified outside of Noesis.

Thanks, I'll go with the named box.

There's another problem (misunderstanding) I ran into.
How does one apply translation/rotation/scale on a per-mesh basis? Is it what rpgSetTransform is for?
Currently I have the following, at least it does translocation Add:
That's what I get now


Want to thank you for Noesis. Its API looks really powerful, even though you need some time to understand it -- no docs. Still, it only took three days for me to get an idea of how it works.

Yeah, rpgSetTransform can be used to actually transform the geometry, as you've discovered. There's no concept of a mesh transform, so for formats that support this typically it's appropriate to unify things in whatever model space you like (by doing what you're doing, and applying the transform to the geometry), then create a paired bone for the mesh containing the transform. This allows handling for all of the export targets that don't support mesh transforms, and allows custom exporters to do the same thing of scanning the scene to filter bones (that are mesh-paired transforms) and/or load mesh transforms from bones.

There's also the idea of storing that transform in userdata, for the mesh, material, or vertex streams. But again, most exporters won't know what to do with such data. Although I believe I do have a userdata protocol for exporting mesh transforms for FBX specifically, if you're interested in using that I can dig up the details.

Thanks for the info. As for FBX, no need to bother, I think I'd rather go the more universal way, as you rightfully suggested.

What's interesting with 4DS format that I'm working on is that it seemingly uses a flipped X axis (a different handedness?). I only noticed that when I saw a steering wheel of a car model on the right side, whilst it must be on the left.

So I figured I needed to apply another transformation to a model to mirror it, I did it this way: After that I had to flip faces, as they went inverted While the model now looks correct, I'm still lost in those matrices.

Is the operand sequence in the trans matrix correct form a mathematical point of view? Do I have to do any operations on a rotation quaternion to mirror it?
Is it ok that if I sequentially apply those matrices with rpgSetTransform instead of multiplying them, it shows a different messy result?
I'm really confused now as I'm apparently lacking some fundamental understanding.

Have I just wasted my time if I could simply swap the handedness? Lol, it seems I have Still , I wonder if it's achievably the way I did it first.

Sounds like you've already discovered RPGOPT_SWAPHANDEDNESS. Seems like you were effectively mirroring the geometry with a transform, but you would have to flip handedness for all of your joint/animation/etc. transforms too. RPGOPT_SWAPHANDEDNESS does all of it for you, as long as you're feeding bones/anims/etc. to the interface via rpgSetExData_Bones/rpgSetExData_Anims/etc.

I wonder, is there a way to not show some meshes in the preview on purpose? I'd say some LODs or dummy boxes. I see I can manually skip render in the data view, but is there an option to do it in code?

Also, I read somewhere on this forum that one can use multiple materials on a single mesh (did I misinterpret?) by setting a name (rpgSetName). I tried doing this, but it still shows meshes split by material. Am I doing something wrong?

Yeah, the best way is just to create a single material with skipRender set to true, and assign all the meshes you don't want to render to use that material.

Yeah, meshes will always be split by material. You can ensure optimal splitting by calling rpgOptimize, or if you just want bucket sorting by material+name and no geometry optimization, you can use rpgConstructModelAndSort in place of rpgConstructModel. You can think of meshes as "draw structures" rather than traditional meshes in this sense, as internally the idea of a mesh is really just a reference to some geometry data which may or may not be self-contained, with information about a single draw utilizing that geometry. Although the way exporters choose to treat meshes may or may not fall in line with this. The way all of this is set up is pretty crappy, but it's been workable. Typically exporters which don't want isolated vertex/index buffers per-mesh will use NMSHAREDFL_WANTGLOBALARRAY.

There's also the idea of multi-pass material rendering for a single mesh, which is what the nextPass member of the material structure is for. But I don't think that's what you're after. If you really wanted, though, you could use this to attach multiple materials to a single mesh, and create a custom per-vertex stream that specifies per-vertex material indices or something of that nature. The Noesis renderer would not understand this concept, but custom exporters could.

I've noticed a concept of a tool exists in the API. Can you elaborate more on this?

Can a tool be used for some sort of format-specific configuration?