Sith Holocron

Adding new texture and eye flashing to droid model "C_ForDrd"

Recommended Posts

I wonder if you could use elements from the textures for C_ConDrdBoss, C_ConDrdL, and C_ConDrdM as a basis? They are all basically the same series with obvious shared similarities, yet those three have 1024x1024 diffuse textures and normal maps, yet C_ForDrd just has a 512x512 diffuse. It may require a remap to accommodate that though, which is likely more trouble than it is worth.

Share this post


Link to post
Share on other sites

Who's on the case? ;) I have a decent progress on the rodians, so I might have some chance to work on the droid.

Share this post


Link to post
Share on other sites

Here are some screens of a 1K upscale effort:

 

http://imgur.com/a/dAkAe

 

I had been planning to work on a new vanilla-upscale pack for all the droid textures, starting with the protocol droids (because I throw up in my mouth a little bit every time I have to talk to one), but since this request came in I figured I'd start there.

 

It also gave me an excuse to develop/use a new (to me) technique, which is using 3d modeling software to bake an ambient occlusion map (in my case the software is blender), and using that map as a shading layer for the diffuse texture (since KotOR doesn't actually have direct AO map support). It works incredibly well on droid textures. On skinned models, it is less helpful, but can still add a little bit of realism (if you use a high opacity on it it makes the model look dirty/wrong, but a little bit goes a long way). At least in Blender, with KotOR models, there's a bit of art even to getting the maps baked properly, so I hope to write a tutorial out before too long ...

 

Anyway, hopefully people like it, let me know! I'll start a WIP thread if I start to make real progress on other droids.

  • Thanks 1

Share this post


Link to post
Share on other sites

I throw up in my mouth a little bit every time I have to talk to one

If MDLOps could ever be fixed (or at least made less broken), we could import some new protocol droid models.

 

It also gave me an excuse to develop/use a new (to me) technique, which is using 3d modeling software to bake an ambient occlusion map (in my case the software is blender), and using that map as a shading layer for the diffuse texture

Are you using xNormal for your bakes? I usually find that the easiest route, assuming you are creating a high poly source mesh via a subdivision surface or the like.

Share this post


Link to post
Share on other sites

I have my own texture that looks good with an exception of the eyes.

 

 

x0QmIVZ.jpg

 

 

Is there maybe a tutorial or simple method to fix this? 

Share this post


Link to post
Share on other sites

Self-illumination, if that is what you are talking about, is handled in the mesh, not the texture. The original model doesn't have any self-illum for the eyes because they are part of the head mesh (and obviously you don't want the whole head glowing). There's currently no practical way to address that for this model. It's not something that can be hex edited, because you'd need entirely new meshes for the eyes. Trying to compile a new model will almost certainly not work due to the issues with MDLOps. The only option is to fake it in the texture, the same as the original texture did. Start by cranking up the brightness.

Share this post


Link to post
Share on other sites

Unfortunate..

 

How does the Kotor 1 droid model have glowing eyes, if there's the concern that the entire head would be glowing?

 

Anyway, thanks for the info. I guess there are limits to everything. :/

Share this post


Link to post
Share on other sites

DP: If I recall correctly, you mentioned that MDLOPS would need to be updated to accomplish certain adjustments in model replacement. Would this eye glow topic fall under the same topic?

 

Malkior: following DP's advice, I wouldn't go crazy trying to add an eye glow. Try the brightness suggestion and see where that takes you.

Share this post


Link to post
Share on other sites

DP: If I recall correctly, you mentioned that MDLOPS would need to be updated to accomplish certain adjustments in model replacement. Would this eye glow topic fall under the same topic?

MDLOps is borked, yes. So is KAurora for that matter (albeit in different ways). It has nothing to do with self-illum/glow specifically, the problem is that you can't compile functional models for many/most droids, amongst other things. In this instance you'd need to split out the eyes to new meshes, thus you'd have to compile a new model.

Share this post


Link to post
Share on other sites

I figured it would be something like that. That's why I pointed out that the glow wasn't necessary. However, it might be interesting to see what these folks come up with - now that a few more people are in the conversation.

Share this post


Link to post
Share on other sites

Here's a glowing eyes version of the model for anyone to use as they see fit. It can also be bump-mapped, if you're so inclined. I did one for mine.

 

C_ForDrd-model-only.7z

 

In case anyone looks at it in detail, you may notice that there's a new head2_g mesh in addition to the new eyes_g mesh. If you've done a fair bit of modeling, you may have seen this weird thing where some part of a model's shadow seems to extend to infinity (often towards the center of the screen)... I started to get that when I made the eyes mesh a child of the head_g mesh (necessary to get eyes_g tracking w/ the head in all the animations). The only solution I could come up with was to make a full copy of head_g (head2_g) and make it also a child of head_g (position 0,0,0). Then I made head_g render 1 shadow 0, while making head2_g render 0 shadow 1. That worked. Yay. I actually used the vanilla head_g mesh for head2_g, instead of the 'eyeless' head_g mesh from this model.

 

I tried a number of other things that didn't help at all, including leaving the head_g mesh pure vanilla. The problem definitely came from adding a rendered child to head_g. Maybe someone will figure out what makes that happen sometime... I assume we will one day be able to fix the compiler to avoid that workaround, but it works for now (I think).

 

Actually, while I'm here, feel free to use my proto-height-map for anything you want as well. I've done about 20 normal maps for this model (none of which I'm that happy with), generally using this one as an input:

 

https://imgur.com/ncIDAsf

Share this post


Link to post
Share on other sites

So, I .. don't know how to install your model files into my game to replace the default model. 

 

What I've done to test it was to change an existing UTI (Terena Adare) and view the results, but for some reason it's still using the old (non glowing) version. 

Share this post


Link to post
Share on other sites

Wellp it seems I was using the wrong Override folder :X

 

After re-extracting it, I keep getting intermittent crashes.. It could be a formatting error or the program simply isn't capable of running the extra geometry or edits. The crashes are "contained" by re-extraction, but after trying to leave the room upon seeing the droid, it crashes and continues to do so if I try to reload the level.

Share this post


Link to post
Share on other sites

Interesting. Can I ask what level you are seeing this in? Is it something testable on my end?

 

I can upload another simplified model without the extra geometry (I forget if I also made it bump mappable, but if so I will take that out too) to test also. Probably tomorrow sometime.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.