Home Artists Posts Import Register

Content

  

Hey everyone!

I’m a couple days late on this post, but I wanted to reach a good stopping point on the lighting stuff so I could show off the completed vision we’ve been working toward with our lighting system. AltairPL has been making a really heavy push on his end, so he has a lot of progress to show already this month. I also have some updated work from TK and our new sculptor to show off. Ubercharge was under heavy pressure to make progress on a project for his master’s degree, so he’s had to devote serious attention to that this past week, but he will be tackling his tasks starting next week.  


Light Path Expressions and Uber’s Light Compositing System

I’ll start off by saying our ideas for drastically cutting down the workload for lighting are working, and the image above shows just that :D.  All nine of these lighting examples were accomplished with *a single render* that took about 15 minutes.  I was able to put all of them together in about a 60-90 minutes while getting used to the grading controls of the compositing software.  This workflow will absolutely allow a single person to manage the ridiculous amount of character lighting our new art style demands for the remainder of the project.

Here’s how the entire process is accomplished:

  • We use Uber’s lighting rig to render approximately ten separate images per pose; one for each light group in the rig (plus one for things like Neon’s lights and dome lighting), thus encompassing all possible lighting situations.  All of the lighting bullshit we went through with the battle test releases pays off dramatically here by the way. I’ll explain below how we’re able to get all the images we need with a single render.
  • I dump the renders into my procedural automation network for portraits/battle artwork and wire them up to “Uber’s light mixing system” as I’ve been calling it. From here, I’m able to use the compositing software to simply adjust the lighting how I want. Make the left light red? Done. Reduce the reflection in Malise’s glasses? Done.  Hate the goofy highlight on Malise’s left boob? Roto it out. No need for re-rendering anything!
  • Once I complete all the renders for the other poses and add a few additional master controls to the network, I’ll be able to adjust the lighting on *every portrait in the game* with a single set of sliders, and then export all of them at once with any additional post processing. This goes the same for enemies once I get that set up.
  • I then use a batch script generator I made in Excel (kind of works like a database for all our portrait data) to create a script that names all of the outputted artwork files automatically. I still have to update this to handle lighting variations and enemies.
  • I then batch re-scale for 720p in Photoshop (until we’re in 1080p) > dump files into game folders :D.  Or more accurately, hand off to APL to dump in the game folders.

It was an unexpected detour, but I spent a lot of my time this week furthering TK’s previous research into Nvidia’s Light Path Expressions. This is a coding framework for the Iray rendering engine that makes some great black magic possible (of course, there’s almost zero documentation available so there was a lot of painful testing involved... for anyone familiar with regex it’s similar). Luckily the work paid off. We’re now able to render all necessary images for step 1 of this process in parallel, meaning it cuts the rendering time by 90% for a pose. Tack on another unrelated trick I learned this week and we’re at 95% reduced rendering time for portraits. It’s a huge weight lifted off me considering I’d previously have to be rendering around the clock to make the above system work.


AltairPL’s Coding Progress Report

My part of ToDo list in the monthly update is pretty long, and I was able to only do the small part from it, but I'm still pretty happy with the progress.

April started rather poorly for me, since I had some real-life stuff on my head, but one good thing that came out of it was the much-needed break from coding, especially from all the battle stuff.

My work this month started with the battle sprites overhaul mentioned in the monthly update. Everything is now much cleaner and less convoluted, so adding and changing stuff later won't be as much of a chore as it would be with previous version. It's still not finished though, since one of the plans for it was to move UI/info elements to dedicated classes to make it easier to implement and change visuals, like for example the UI idea Ero posted in the monthly update. I decided to leave it for later and shift my attention to double-teaming, since its visual side was already taken care of during finished part of the battle sprites overhaul.

Now that I think about it, I'm sure we could/should come up with a better name than double-teaming, since the way it's implemented allows for pretty much unlimited number of stacking enemies... and I think Ero already has plans for holds with three enemies at once. Anyway, shortly after shifting my attention to the multi-teaming(?), I've noticed that some hold stuff was still poorly done and it could/would kick me in the butt later, and since it was kinda in line with the multi-teaming stuff, I decided to do both at the same time. The idea was nice, but of course something had to get in my way. In this case, this something was a prototype for H-stat tracking, which was tied to the previous approach. I had only two choices here - either completely yank it out and implement it somewhere along the line or to add it to the current workload. Again, it was somewhat related to the stuff I was doing, so I chose the latter.

To be honest, I think I got a bit carried away with it, but hopefully people who like stats will appreciate it. The prototype was only tracking number of stages of H-skill chains (hold, H-skill, finisher), so I've also added tracking of target body parts for the last two stages (H-skill, finisher). This required some careful planning, but I think it came out rather well... at least for now.

After getting H-stats tracking out of the way, I was able to finish making changes to hold stuff and finally start implementing multi-teaming logic. Since no art dedicated to multi-teaming exists yet, I had to use some old enemies and art for testing by making copies of all needed database elements and adjusting it accordingly. After that it was pure coding, testing, coding, testing, ... Suffice to say, conditioning for enemies joining the fun seems to be working just fine, so now I need to focus on fixing some more or less minor issues and come up with some neat ideas for the behavior of enemies who are already holding an actor when another joins in, such as pausing or looping one chain skill if an enemy that can join the fun is available. Oh, and I must not forget about adding support for inanimate spawned “enemies”, like handcuffs, which shouldn't be able to act in the first place.

Well, it was going well so far, so I really hope nothing blows up in my face and I'll be able to finish all the battle stuff and start something else from the ToDo list before the next IC update.



Ven and Splicer Overhauls

TK has finished remaking the textures for Ven’s legs, and he is nearly finished with the new model for her arms. The texturing process for these will be a lot simpler after having done the legs. I haven’t gotten my hands on the final leg textures yet, so the only screenshot I have is a low-res one of TK’s from Substance. I’ll probably rough em up some more once I get them into Daz :D. That said, the new textures get rid of all the baked in gradients/shadows that don’t make sense for physically based rendering.

Our new sculptor has been plugging away at the Splicer assets, and she’s has finished the model we showed in the monthly update. She’s since been working on variations for materials.

That’s about it for now! I always feel kind of meh when the majority of our work for an update goes into technical stuff, but hopefully the value of it is evident :D. Thanks for bearing with us through it! 

Files

Comments

CrocoKyle

Being honest here, I didn't read the whole post, (Im a bad Inner Circle member, I admit) but I'd like to toss my thought about the lighting picture into the fray - in the darker lighting colors and details, she's almost completely hidden. I'd suggest we brighten her darker lighting situations so we can still see details of her armor, like breakages and fluids. You guys did a lot of work overhauling the art and I'd hate to lose that in dark lighting. Just my thoughts!

eromancer

Those were put together entirely to show off the flexibility of the compositing system -- they don't reflect any environment in-game.

CrocoKyle

And that, folks, is why you read the whole post before commenting. Thanks Ero!

eromancer

In the interest of dispelling widespread panic (since people were already worried the lighting would be too dark), I redid a few of the dark examples that didn't need to be dark to show off what I was going for :D. Also shows how fast the system is -- was able to redo them from scratch very quickly~. Also, I kind of hate that Patreon has a nearly white UI when its purpose is largely for showing off creative content. It was a very dumb move =/.

Noodledoodleopolis

2 flippin years. Keep up the epicness and remember not to get burned out. I can wait as long as it takes :)

Anonymous

Albeit technical and not entirely to my understanding, Ero's lighting showcase and Altair's contentedness with the coding gets my hopes up for the pace of content creation once the behind-the-scenes stuff is done. How well does the lighting system handle fluids, for instance with shine and reflection? Is that baked into the fluids themselves? Also, rounding things off before an update seems like a good idea to me, what with showing off results like the lighting. I would however prefer if you'd post a quick comment saying you'll be needing a tad more time to round things off since the inner circle updates have been mostly weekly. Not a necessity of course. Don't want to disrupt your workflow.

eromancer

The lighting system will perfectly handle fluids (notice how it handles reflections on the suit/glasses), but I'm considering a system for variable fluids on portraits that would sacrifice some detail in order to reduce the number of image files required. Depends on how it looks, but I think it could work well for the distance at which portraits are rendered.

ogre five

Can we get another version of that lighting render with the next progression of battle damage? For science.

Anonymous

that looks awesome! good job ! ... i come to think of something... where is onyx? =P

eromancer

Heh, you reminded me I still need to figure out how to create a widget for saving light "presets" within the compositing software :D.

Anonymous

Curiosity, do you all have some sort of project-wide design doc? With the level of complexity and interconnection of all the various parts of the game it might help to have something like that for internal use. I would also like to take a second to mention backups and version control. I know you're a capable team, so I hope this doesn't come off as condescending, but I've experienced large-scale data loss before, myself. Just a friendly reminder on this wonderful Friday the 13th.

eromancer

Yup, there's a 50 page development notes document, a design document for each major release, and an approximately 100 page story document :D. That doesn't include the low level code documents APL keeps. And yeah I backup to a separate disk pretty often, and store old disks separately.

Purple Witch

Always happy to read these updates, the Lightning renderflow is neatly working, which rocks, and the coding part got me quite excited, to be fair! I love your work, people!

Anonymous

Hey Mr. Ero, when can we expect the next update? Coming from a place of eagerness.