RODOH has cometh!

-superChrome

Enjoy!

Does this mean I can get chrome spinners on my Hiig BC? :heart_eyes:

1 Like

That explains a lot about why levels using my old background files look wrong. Fascinating.

I’ll get some side by side shots of two his one rodoh->hodor and one without any change from 2007 there is a noticeable difference in the spec falloff and how refl is handled. The hwc looks much more pinched and the rodoh is more diffuse. There may be some thing going on with the normals or son other surface parameter

I recorded the FX issue I was having with ships being destroyed. In this example I used the Torpedo Cruiser, but it is happening with most of the capital ships I converted over from classic to remastered. Basically, the enemy Torpedo Cruiser fails to spawn its death FX when it is destroyed, but the same ship type properly displays the death FX when it is destroyed/scuttled:

okay, as side by side as I could get. The left Star Destroyer has been through the RODOH->HODOR path, the right was last edited in 2007 and exported from maya. the only difference being the bridge tower texture and ship files. (ISD I vs ISD II) specifically look at the engines and the sharpness of the Specular on the left vs right

when I take the RODOH exported SPEC.tga for each original hod and overlay them in photoshop and use the difference layer option the image is 100% black, so the exported RODOH files are consistent. The same RODOH exported SPEC.tga was used when it went into HODOR. I don’t believe I changed any surface smoothing or mesh parameters when I set up the new max/DAE file for the ship hod on the left.

I have also noticed that the GLOW mipping of textures is much much sharper in the new graphics pipeline and I think some of this is also getting exposed when going through RODOH as the SSD’s above certainly had much more pronounced window lighting after I moved them into the new workflow. This is actually a good thing as before in HW2 classic at distance or angles the glow /diffuse would mip would get all muddy and blurry, now my biggest issue is I need to redo a lot of textures…

1 Like

The really weird thing is that when you think it failed to show the FX, you still see the lights from that FX. You just don’t get any particles. So actually I don’t think it is quite so simple…

How easy is this to repro? 50/50? 20/80? Maybe consider sending me your ship (the full folder) - and I will see if I can repro in the same conditions.

Maybe give me both ship files? I can run some tests to see where the delta is - it may not be a bug or issue - but I would still like to understand it…

FYI - I think I have a pretty solid fix for the busted ‘Root’ Animations issue. I’ll explain:

When I created the DAE transport code I was careful to consider that each ‘root’ node may need to be moved for various reasons. I effectively made the root location irrelevant to the processing code. The trouble then is that if you animate the root, suddenly the location matters a great deal!

So my plan is to allow a node to exist under ROOT_LOD[0] called JNT[Root] - which you can animate. It will be a special case, in that if it is present, the code will ignore anything else connected to ROOT_LOD[0] and dig only into the JNT[Root] tree (so, like a proxy root).

RODOH will be updated to support this. Probably very early next week.

Additionally, if you’ve lost root animations but also done work on a mesh after, you can re-RODOH it to another DAE, and then just copy/paste the JNT[Root] and it’s animation channels into your old DAE. Then re-link it to the ROOT_LOD[0], and link the children under ROOT_LOD[0] to it - and you’ll be back to correct - without any other fuss.

I’ll update again if I hit any issues, but I think it will be fine.

2 Likes

Probably 50/50. It is mainly occurring when the ship is controlled by another player (in this case, the CPU player). But when the ship is controlled by the player, the FX is spawning most of the time.

I was having this issue was well, glad to see a solution may come up.

@BitVenom

Confirmed that “FX doesn’t show” issue happens for certain ship (even some GBX’s ship that isn’t modified) in certain situations. Can easily repro , 100% happen.
It seems that it happens only when the ship comes into the game from hyperspace . For certain ship it only happens when the ship is controlled by your enemy . Ship which is built by other ship and doesn’t come out from hyperspace won’t have this issue.
UX is writing a rule file to show you when and how that problem will happen.

1 Like

Can confirm about the hyperspace thing, legacy hod worked fine, ran through RODOH -> HODOR and effects don’t play

bitvenom, I’ve got a bucket full of hods that didn’t convert properly that I am uploading examples of. These were all exported from RDN maya and never were touched with 3rd party tools.

For the TIE fighter and corellian frigate the mesh is completely borked, it has verts and edges but no faces, this is probably the most common issue I am seeing, probably about 20% of the ships

FOr the star destroyer the texture coordinates are hosed in game, but looks fine in the DAE from RODOH.

For the destroyer ship yard the animations/dockpaths have failed. Ships will just hyperspace in around the facility and the animation does not play.

@EvilleJedi


UX has written a report about that “effects don’t play” BUG. It seems to have nothing to do with HODs and is a BUG of the game itself.

I am looking into this (along with a ton of other things on my plate)…

Send 'em my way. Some of this will be hard to fix, some won’t - so we’ll see. If I have to ‘manually’ fix a HOD by hacking in RAM before processing, I may be able to do that as well. I see your PM, and will get to it shortly.

Do they work before RODOH in HW:R? We changed lots of stuff there, and maybe the break in that case is more about the new systems (and flags) than conversion. I’d love to be able to validate that one way or the other though.

In my case, player-controlled ships display their FX just fine. It is only CPU-controlled ships that don’t display FX if they have hyperspaced during the game. This happens with both the original and RODOH conversion HODs.

2 Likes

The destroyer yard hod I uploaded works fine (original from 2007) the rodoh->hodor path breaks the docking path and the animations as well as the doors being reoriented in a weird way.

The bigger rodoh issue is the missing faces. I am going back to the source meshes and I am not seeing any flipped faces or other major geometry issues, so it was something that happened in the maya pipeline (I did all of my original modelling and texturing in 3dsmax and then exported to maya for rigging using RDN plugins)

after looking through hods converted to dae with the new format for parameters, it would be really helpful to group markers together, nav lights together, repair points, salvage points etc. the schematic view is really long now, and the search is only useful to find single items since the tree can get very large. I tried using the layering system in max, but it doesn’t help much more than for viewing, selection sets are better, but it takes time to enter everything into them and there is no ‘unselection set’ to be able to find orphaned items like the layers have a default layer. Looking for some tips on how to manage the number of dummy nodes since even a hardpoint has at least 3 objects

just to give an idea, the uncollapsed hierarchy for my star destroyers is 3 pages of this

have you tried using the scene explorer window in max instead?

The best and worst thing about max, 25 different ways to do almost the same thing!

Thanks that looks like it will be a lot easier to manage (at least it starts collapsed)