dreamCloud

Oh? Nice! I'll download that and have a look through it over the next couple of days.

Awesome, glad one of those was the correct answer!

Sent via DM

Yeah it's all about the morph animations. You can still use your same mesh if you are committed to that, you'll just need to use option 4 and make the tri files for that. As for the neck moving like the vanilla neck, you need to parent it to the skeleton and then weight paint the neck part of the mesh to the neck bone, spine2, clavicle l, and clavicle r the same as the Vanilla head is done. One big downside of using the hair slot for your mesh is also that the hair slot defaults to only being weighted to the head bone (it's something a lot of hair modders complained about early on and their workarounds was to make helmets). I have a bunch of old tutorials I can dig up too if you really want to dive in.

Could be a few things wrong with it from flipped normals (if it's single sided mesh that causes backface culling and it won't show up in the game) to the rigging being off (sometimes that will send the mesh to/through the floor, commonly caused by not selecting it when you import the skeleton or vice versa) or even something wrong with the data block in the .nif file itself. Try checking those things first, if you're still struggling I can take a quick look at it for ya.

To get a proper custom head mesh into Oblivion you need to do one of four things: 1) Edit the vanilla head mesh in a way that does not interrupt the vertex order (CRITICAL). This can be done fairly easily in Blender 2.49b or 3DS Max 8/9 by pinning the vertices at the very bottom (the ones that line up with the neck) and then applying a shrinkwrap modifier to it so that it matches the geo of your custom head mesh and then cleaning things up by hand so everything sits right before exporting. 2) Edit the head06 head mesh the same way as 1. It's here on the Nexus and is also what was used by other people who did big race modifiers. It's basically a vanilla-ish head mesh but with way more geometry applied so you can sculpt it a bit. 3) Create a new head mesh using the Facegen tools that lines up very closely to a basic Facegen mesh. This takes forever, it's prone to errors, the software is extremely old, and it's expensive. Ironically though it's still being used in some current games. But it will give you the correct morphs for the game engine. For some reason I only have a 50/50 success rate using this software though. And then you'll have to probably edit it like option 1 anyways to get it to look right in the engine (especially around the eyes, man this tool has trouble with eyelid animations on anything not super exact to its base mesh lol). 4) Create a brand new head mesh (like you've already done) and then hand-make a tri file for it that includes ALL of the morphs that Oblivion engine expects. This may be the most reliable way for you with your experience, but it takes forever and you can easily mess things up (ask me how I knoooow lol).

Ah ok I sent them a DM. Hopefully they can point me in the right direction.

Thanks Andalay. I managed to extract (most of) the text from the corrupted files at least, but without the images that went with them I'm kind of treading water as the obscure references to the UI for 3DS Max 8 is... not great to navigate for someone who grew up on Blender. I did manage to at least get an animation working in 3DS Max itself, but can't figure out how to export it correctly based on that text alone. Keep getting errors. The only reason I was able to get that far was due to some old 3DS Max 8 videos from a class I found up on VEOH before that site dies (it's getting pulled down... we are losing soo much information recently ) Feels like I hit another dead end. I had created several particle systems in NifSkope based on that old 8 hour long Morrowind tutorial video still floating around (which is a suffering I do not wish on anyone) and tried to change the .nifs around to Oblivion's formats based on existing .nifs in the game. I ended up getting ctd after ctd and with no error messaging to tell me what went wrong I figured I'd try the 3DS Max route. Took a very long time to find a copy of 8 to work with the civ IV exporter which apparently is the only way to get working particle animations from it.

Was called "Oblivion 3DSMax Animation Tutorial" Used to be located at http://saidenstorm.googlepages.com/oblivion3dsmaxanimationtutorial But that page has been down forever and isn't on the Wayback Machine (it has 3 snapshots of a dead referral page 302 response at crawl time error). My local copy got corrupted and I really need the part on the particles set up for something I'm doing... although having the whole thing would be preferable as I can't remember all the setup steps for working in Max to get a proper export with the Civ4 tools anyways.

For vertex colors in Blender 2.49b you edit them in the mode dropdown and choose Vertex Paint. One thing about Oblivion is that it does not have support for Ambient Occlusion (shadow detail maps basically), which is one of the design holdovers from previous generation of game engines. Back then they used to bake the ambient occlusion/shadows into the texture maps themselves or use vertex shading. You can see a lot of good examples of this in the book "3D Game Textures - Create Professional Game Art Using Photoshop" by Luke Ahearn (1st-3rd editions) which were published around that generation of games. Oblivion models use a bit of both. If you want to make a vanilla-esque object you have to take that into consideration. It's why a lot of models provided as Modder's Resources on this site often look really out of place in the engine; because they don't have shading details in the color/diffuse texture maps and don't have any vertex coloring to match the vanilla models. To get them or models you make yourself to look correct in the engine you've just got to add those details yourself. Also something to note: when exporting between Blender modern and 2.49b versions or from 3DS Max to Blender back and forth using a 3rd party format like .obj you will have your vertex paint data stripped and it will need to be painted back on.

Ah true enough, forgot about that. I've never done it, just remembered that you can. Just use the refid name you've given in the field for your script (the "player.moveto ReturnHomeMarker" example I gave).

Import the Morrowind NIF file into Blender 2.49b with the niftools scripts. Then export it to an Oblivion nif file. Since it's just book jackets, you can also just try redirecting existing Oblivion book NIFs to those textures using nifskope if the UV layout is similar enough. If you want the actual geometry from those files you can also copy and paste the block structure from the Morrowind nif over to an existing Oblivion book nif in nifskope, replacing the book's geometry. Make sure the texture paths are where you want them and save. Should be good to go either of those methods.

Easiest way is to put in an X-MarkerHeading marker and mark it as persistent and give it a name like "ReturnHomeMarker" or something like that. Then give the player an ability or spell that when used runs a simple script attached to the spell/ability that returns this line: player.moveto ReturnHomeMarker or player.moveto 012324123 (where the number is the reference ID of your ReturnHomeMarker) or you could even just move the player into the cell without a marker. It should place you nearby your door or at the very least the cell's origin (this is also why I like to put the entrance to my interiors near the cell origin just in case of bugs). You could even make the script fancy by detecting if the player is in combat before allowing the portal and returning a message like "Cannot teleport while in combat..." if so. Second easiest way is to have a holding cell and put a door there, can even make it a magic portal door or something and then give it a teleport attachment to another door in your player home, move that door out of reach of the player but move its heading marker into the house proper so they still port inside but can't activate your door that's out of the house to get out to where you ported from (unless you want to for some reason). Then on your script call you'd move the door to the player, offset in front of them a bit, and that door becomes a "magical portal" to enter your player home. To make things clean I'd also suggest moving the door back into the holding cell location after moving through it. There is the downside of NPC's also using the door (upside if a companion NPC I guess) but you can also give yourself or any companions a key and make it require the key to move through it. Third way is to use the rats (or any other disabled creature really) as the Mark and Recall spell workaround so it acts like the Morrowind spell.

I'm actually working on something that will touch on this. But it's part of a huge overhaul project and it's kind of on the backend. I also only had 4 extra dungeons planned and only 2 of them actually mapped out. Might get around to implementing them soon, but I'm working on the hardest stuff right now (new animations/quests/tons of new assets) so it won't be until the end of the year at least I think.

So I've got quite a few animated files for creatures in .fbx format (and some modern .blends too, both bought and made by me) that obviously 2.49b can't read/open correctly. If you've ever used Blender 2.49b's animation system you'll know how insanely difficult it is to work with so I'd rather skip the step of re-creating all the rigs, weighting, and animations frame by frame in 2.49b (which would also be weeks/months of work). There has to be a file format that 2.49b can read (I'm using the portable version of X-Blender 2.49b that has all the import/export plugins that I know of already) that modern versions of Blender can export to. So here's the ideas I've been thinking of, not sure how viable they are since there's not a lot of documentation on these plugins on whether or not they support animation...: - Collada .dae files can have animation in them. I noticed in Blender 3.6 it's still an export option and is also an import option in 2.49b. Although the only people seeming to use it are modders for other games like Doom 3 and they have tons of issues with the animations. Unsure if this is a possibility or not. - I found a plugin for MilkShape 3D .ms3d for .fbx files that might be able to work. I have no clue what settings I would need to use or not though and it's in beta status from 2011 so... who knows? Basically import the fbx with animations into MilkShape 3D. Then export that as a Milkshape file then import the Milkshape file into Blender 2.49b then export into .nif/.kf from there? - X-Blender 2.49b can also import .psk and .psa Unreal Skeletal Mesh/Animation files. There is an exporter for that for Blender 2.8, which maaaaay work in the newer Blender versions? - Lightwave MDD might be an option by converting armature animations to mesh animations as shapekeys. Load up the fbx/blends in 3.6, export an MDD. Load up the mesh (from whatever export, obj maybe?) then apply the mdd using Load MDD to Mesh RVKs? I'm really guessing at the workflow here. - The Sims 3 uses the .geom file type which can hold animation data. I noticed X-Blender 2.49b can import that and there does exist a plugin for exporting sims 3 .geom files for Blender 2.8-3.x. |----> This might also work for .md2 Quake files since they hold vertex animation kind of like how a lightwave MDD does. - There's also the possibility of converting .fbx files to DirectX .x files directly using an online converter or through Milkshape3D. Heard varying results with that and that it mostly does preserve animation data, but I have NO clue how Blender 2.49b's .x importer handles animation data. Has anyone tried any of these methods before?

No worries, facemaps was in the original poster's error logs as the source of the error on export.

To update everyone: I did find a workaround that looks exactly the same if not an exact solution! Here's how I did it: Made tiny cubes for each crystal bit and moved them into the location and matched the rotation of each crystal Copied the location/rotation keyframes for each animation frame from the crystals to the cubes (by hand!) but don't parent the cubes to anything Then unparent the crystal bits (this will make them go all over due to the bad transform info that was causing the bug originally, but this will be fixed) and cleared all transform data Set the crystal bits to the cube locations Parented the crystal bits to the cubes, they didn't have any bad transforms so as they parented they stayed put Deleted the empty I was originally using to power the rotation animation since the cubes were taking over for that Animation plays exactly as I had it! Had another issue of the cubes showing up with a black material even though I set them as collision type and had already removed any and all materials on them (so should've been invisible) so I ended up collapsing all the vertices of the cubes down to a single vertice. Ironically the blender animation export still kept the location/rotation transforms even on the single vertice, so it worked and everything looks right!

The newer Blender nif scripts only properly export back to Skyrim's versions of NIF unfortunately, unless something changes in the future. To get a nif file Oblivion can use from a newer version of Blender is quite the process but is totally possible (I do it all the time). You'll want to save your file as an .obj file, then import that into Blender 2.49b then adjust things as necessary (rotation is a big one since .obj tends to switch the x and z and I've noticed scale can be a problem too), apply rotation and scale, make your collision in 2.49b and then export to nif from there choosing the Oblivion options. As for your direct question, I'm afraid I've never heard of "face maps" either until now so I did some digging. According to this post face maps are like vertex groups but for faces. They are used for quick rigging animations... so not sure why that is being brought up as an issue for your file by the exporter ¯\_(ツ)_/¯ https://blenderartists.org/t/what-are-face-maps/1252657

Hello there! I've been trying to make this animated static for a while now and I keep having an issue where a few rotating bits on the end keep getting extra data somehow and end up way offset from the rest of the mesh. Here's how it is set up: - Rod, collision is parented to it - Broken crystal on the end, parented to the rod - an Empty parented to the crystal, provides the rotation for the crystal bits - crystal bits a bit offset from the broken crystal, parented to the empty ---> After moving the rod the crystals separate (using loc keys) then start spinning (using rot keys on the empty) -----> I had spun the empty on the Y axis for the rot keys then parented it to the broken crystal to get the bits parented to it to follow the rest of the animation, otherwise the rotation of the empty gets weird (and can't figure out how to rotate it locally in 2.49b) Everything works perfectly in Blender itself... When I go to export it everything works in Nifskope as well except for the crystal bits. They are always waaaay offset and spin around the entire scene which blows the whole visuals. I've tried: - Clearing origin/location/scale/rotation data and then applying rotation/scale, this did nothing (it did break the one working part of the animation though ha!) - I completely remade the entire animation from scratch again. Got the same result. I also tried - Making an armature and remaking the entire animation from scratch again using bones, thinking it was parenting the bits to the empty that was causing the issue. Although for some reason this turns out way worse (the armature always ends up rotated way off and the animation just ends up flailing around like a dead fish, plus the collision stops following the meshes this way and for some reason none of the meshes even show up in-game [wild, what a disaster, and an entire day's worth of troubleshooting didn't fix any of those issues]). So I went back to my first plan... but I'm still having the original issue

Looks like Autodesk finally revoked my license for my educational 2010 version of 3DS Max. So that's off the table. I am encouraged that some of the screenshots from the one user show Blender's UI though, so they must have found a solution in Blender. I ended up finding the relevant mod in question where they solved the issue for neck seams, so I know it can be done for my cave model... just... how? https://www.nexusmods.com/oblivion/mods/44360

So it seems for sure where the vertex normals break is exporting from Blender 2.9 as an .obj. I double-verified this by exporting one tile piece as an .obj, deleting the piece and re-importing the .obj I just made. The .obj had broken vertex normals that did not match the tile next to it (ie, the ones I made in Blender before the export are now gone).

Been working on a huge tileset for Oblivion for quite some time. I followed some guides on how to completely eliminate seams in Blender by using the Data Transfer modifier to copy vertex normals from one tileset piece to the next. It worked great and looks amazing in Blender (the same way that one modder did for solving the neck seam issue). However, my problem comes when I have to export. Since I have been modelling in 2.9 I tried the new 2.9 nif tools export. However, it must still have a lot of work to do to be reliable because every time I try an Oblivion export I get so many errors and I tried to parse through and troubleshoot them all but it's become beyond tedious. So I then tried to do the old export way of exporting to an .obj and importing into 2.49b and re-exporting as a .nif from there. That works, but I notice that I lose all of my vertex normal information I worked so hard on upon doing that. In-game the models no longer have the same vertex normal positions and the seams are back. I verified it by re-importing the .nif files back into 2.49b and looking at the vertex normals in there and they were split. I thought I could try fixing it in 2.49b but it doesn't have the tools to do so. I then tried the copy/paste method into Blender 2.7 and importing into Blender 2.62 and saving it as a legacy save then exporting from 2.49b again but I lose a ton of geometry data (lots of missing faces) when I do this. I know that there is a way to get .nif files with the correct vertex normals in-game since another modder did it to fix neck seams, but I am at a complete loss as to how and I am unable to contact them to ask how they did it. I've troubleshot the files quite a bit already. They have the same material, they are lined up perfectly where the seams are vertex to vertex and I also flattened the area around the seams so they are parallel to prevent any light bouncing causing it, and I double checked the textures are perfectly aligned at the seams and I updated the tangent space in Nifskope as well (this only changed some stray reflections, the seams are there before and after). Example attached showing 4 separate tiles looking awesome next to each other in Blender and in-game showing huge nasty seam. Notes: - I do have 3DSMax 2010 (one of their free versions offered to students back when) and the nif scripts for that, but I never caught on to 3DS Max and it's very alien territory for me. If there is a way of getting my model from Blender 2.9 to 3DS Max 2010 without losing the vertex normal data that might be worth it to me to learn... but scouring the web hasn't found anything for that for me (again it seems to be exporting to a 3rd format that is losing the info). - Are there nif scripts for 2.79 maybe?