Archangel35757

@@Xycaleth- But if the game code is always calling the same function or method to compute the bounding box, or get the bounding box from a method, or check against a supplied bounding box, then maybe it could be replaced without too much pain, no? I've not honestly looked at the code...

@@DT85 - Oriented Bounding Box (OBB) would be better, yes? There is code online for it. @@Xycaleth - how difficult would it be to replace AABB with OBB (or something better-- i.e., Convex Hull)? Is the class and code for it modularized?

...oh, naturally I was meaning you-- not me. I wouldn't know where to start.

any chance you could push what you have now and set up to build concurrently?

So has there been upgrading of the code for Bounding Boxes (used for collision detection)? If I recall, JK uses the Axis-Aligned Bounding Box (AABB)... on the simple side ...but not the most optimal sloution.

...but then came along @@SomaZ -- nice thing is... he can take @@Xycaleth's new ModView repo as a baseline to start from. I would suggest this after the renderer is considered complete or stable.

You *might* be able to reduce the legacy GLA jitter... by deleting (i.e., reducing) keys so that you only have keys every 8 frames or so... and thus let the animation controllers work between the keys... you can find scripts on Scriptspot to do this. I would give this one a try: http://www.scriptspot.com/3ds-max/scripts/gtvfx-anm-keyreducer

@@Tompa9... yeah, sorry-- I steered you wrong... If you want dismemberment to work then you need to parent the mesh hierarchy in a similar fashion to the bone hierarchy. Just load up a standard model.glm in ModView and look at the mesh hierarchy under the surfaces branch and make yours accordingly.

that's quite true... libraries are this way-- the C++ code isn't available to view... all you get is the prototype definition in the header file and hope they library has well documented help to explain the method in some detail.

@@minilogoguy18 - study @@eezstreet's resources here, and all the parts of that Softimage "importexport" example we both compiled. What we come up with for an MD3 exporter will be similar in some respects (accessing the geometry and its properties, etc.)

...but when he ignites the lightsaber at start, he does appear vaguely in the middle, duller spheroid object (or was that only the saber blade? ...hard to tell)-- so why is that? Hmm... maybe Anakin is a Vampire (and doesn't cast reflections)?

Why is Anakin not reflected in the shiny mirror-like object? Also, somebody needs to re-texture that anakin... as his clothing looks made out of rubber. (or use another PBR model). Maybe ask Scerendo to upgrade his Aayla Secura and/or Quinlan Voss models with PBR materials

Thanks for the schooling...

@@SomaZ - you mean Albedo is missing, correct? Keep up the great work!

@@DT85 - I'm pretty sure even the root pose (root.xsi) needs to export frame 0 and 1, even if things are not moving the objects are still keyed in the root pose, so that's two frames of animation... right? Unless you're referring to exporting a static mesh for the purposes of baking a normal map? What some people forget to do is change the length of the animation time configuration from the default 100 to 2 or whatever the actual frame length is.

With the advent of the DF2 Rend2 renderer... thanks to @@DT85, @@Xycaleth, @@SomaZ (and others who've contributed...), Level Design Artists now have the opportunity to learn next-gen mapping techniques and workflows using Physically-Based Rendering (PBR) and Imaged-Based Lighting (IBL). So I thought I would start a new topic that had Level Design tutorials (maybe not specific to our game engine) using these new features. Here's one link: http://www.cgmasters.net/free-tutorials/what-to-know-when-creating-next-gen-assets/ ...and this site may be a useful educational resource for Level Design: http://worldofleveldesign.com/categories/cat_level_design_tutorials_tips.php Others, feel free to post tutorials and topics, resources, etc. that will help the Level Designers in our community to transition to these next-gen workflows.

There are three dotXSI exporters on that page you linked. The Blake Robinson and Autodesk Crosswalk plugins WILL NOT work correctly with Carcass. The Crosswalk exporter generates a dotXSI 6.0 file (and Carcass v2.2 only supports valid dotXSI 1.1, 1.3, 3.0 and 3.5 file formats). If I recall correctly, the Blake Robinson exporter will generate a dotXSI 1.3 file specific to the Battlezone2 game (is this the one you are referring to where you say it generates a "xsi 0200txt 0032" file (meaning a dotXSI 2.0 file)? That Pandemic-based exporter is not compatible with this game engine. The CORRECT plugin is the one there submitted by me (dotXSI 3.0 Exporter v1.9)-- it is the exact same plugin as hosted in the JKHub Utilities section I linked you to earlier. The "dotXSI 3.0" v1.9 exporter is the plugin you have to use (if you want your stuff to work). Now, please post a picture of your export dialog settings that you used... I just want to check how you set the options.

Where did you get that "bad" dotXSI exporter plugin? And your screenshots showed you were using carcass 2.1. Use Carcass 2.2.

what happens when the model is dynamically lit underneath (e.g. lights shining up through metal grates-- would that change the effect of cavity maps?

@@Almightygir... makes sense-- tighten up the AO and let the cavity map handle the grosser areas. But are they kept in separate channels or merged into one texture map?

3ds Max has the "Optimize" modifier... try googling 3ds Max specific tutorials.

Where did you get your dotXSI exporter? Post a pic of your dotXSI exporter settings. You should be using this exporter (verified working properly): https://jkhub.org/files/file/2612-3ds-max-9-dotxsi-30-exporter-3264-bit/ Also, you are using an obsolete version of Assimilate and Carcass. You need to download the latest Assimilate and Carcass v2.2 from our Utilities file section.

But they are not the same thing... right? @@Almightygir - what is most industry practice for AO & Cavity maps? What if AO was in the Blue channel and the Cavity map was in an Alpha channel? I don't know what I'm saying- lol. @@SomaZ - I suggest you just transition all the nomenclature and switch over as Lee suugests now so folks can get used to the new terms. Maybe provide the industry definitions too.

so the AO and Cavity maps should be separate channels? What if you used an RBGA?

Also, can the dynamic lighting (or whatever) make use of IES light data?