The next chapter of Quest of the Key is now available. A lot of Daz assets, custom motion capture, composed in CC/iClone, rendered in Cinema 4D. CC/iClone have really made the animation process so much easier (relatively—animation is always hard 
), and I think with better results. Let me know what you think!
loved it, well done!
As always, very entertaining. The dialogue is fun to follow. Hopefully, it’ll continue soon, even though I know there’s a lot of work to be done for one episode.
Wonderful, as always. An inspiration to us all. 
Nice and well done!
Thanks! Glad you enjoyed it.
Thanks! Glad you enjoyed it
Thank you! Acculips really helps with selling the dialog, and keeps getting better–it’s now more a task of tweaking than fixing. “Soon” is a relative term in animation as I’m sure we all here know LOL.
Thanks! I think we all learn from each other, so it’s great to have a forum like this.
Thank you!
Another fine episode. Also appreciate the subtle improvement in details and render quality (thanks to Redshift?).
While I have a couple of minor nitpicks/suggestions, the overall quality is exceptional.
Thanks! Yes, this and the last ep were using Redshift–got a decent GPU (rtx4070) that does a pretty good job. Still, it’s an arms race against wanting to do more complex things because I can, so some renders are still pretty long, like shots that literally took days to render.
I’m open to suggestions! There are things I know I would change or want to do better (sometimes you just gotta let it go) but I may not have seen all of them.
OK, here are some nitpicks.
Tim,
I just had a quick look at the original Aurora film( 4K version).
You say you have switched to Redshift, but honestly unless it is just way way faster I am not seeing any major visual quality improvement over the older Star Trek fan film
made with the standard renderer.
@Nirwana: thanks for the “nitpicks”–it’s always good to have another set of eyes on something. 
For a lot of these, I guess it’s why big productions have production meetings to catch little things that stand out to other animators, tho some may be intentional or stylistic choices that I guess people will have to decide if they work. Stranger’s stiffness is his personality, as you suspect. The blue lighting I amped up so–visually–the whole video isn’t just shades of brown, and also to make a more dramatic and cartoony color scheme, tho it’s possible to overdo these things. The captain and sailor are “NPCs” to use a gaming term, so I didn’t want to introduce them as characters per se, since, narratively, this episode is when the “party” for the series is finally assembled–I wouldn’t want anyone to think they are main characters that we’ll see again. (And the captain is the character from Auroratrek–just a little easter egg.) I agree that–looking at it afresh–the eye spot in the final shot should be on the other side. In the larger sense, eye lighting is the bane of my existence, and It seems to be a limitation of the C4D software that I can’t seem to be able to light the eyes separately when a character model is inside a subdivision surface object that I use to give them better mesh resolution. I’ve tried to figure out how to do it a number of times, to no avail, but maybe I need to break down and ask on an official forum, then maybe I can try your technique. In any case, thanks again for giving this a look!
Thanks for checking this! I do agree that the improvement is subtle and that I was able to achieve similar lighting to Redshift in the standard render. The disadvantage of Redshift certainly is the render time, but the advantage is that lighting a scene is a lot simpler for me with Redshift since it calculates reflected lighting that with the standard renderer I’d have to fake with a bunch of lights all around the scene–particularly to fill in shadows–so it’s a bit of give and take, tho maybe I’m erring on the side of laziness LOL. I’m hoping that the next GPU upgrade will finally catch up to the demands of the software, but it sometimes feels like an endless arms race.
and It seems to be a limitation of the C4D software that I can’t seem to be able to light the eyes separately when a character model is inside a subdivision surface object that I use to give them better mesh resolution. I’ve tried to figure out how to do it a number of times, to no avail,
Could this be a Redshift lighting conversion issue not recognizing item under the subD object ??
I did a quick character export from my old CC3 to C4D with the standard renderer and lights I was able to exclusively light her eyes and hair even with them all under a subD object.
I never had that issue with Redshift, so I’m not quite sure what problem you are experiencing.
That said, I usually don’t put my entire characters into a subdiv surface because I like more granular control; instead of subdiv, I use RS tessellation (RS object tag) which allows me to use different levels of subdivision on the individual character meshes (e.g. I sometimes find that I reduce/disable subdivision/tessellation on teeth and increase it on hair) and also supports displacement maps.
I moved from Standard to Physical renderer in C4D some 10+ years ago, and after I switched to Redshift (about 7 years ago), I never looked back.
Quest of the Key is a long-term thing, the first chapter came out two years ago (I rewatched all five chapters yesterday) and I do notice differences, especially with character textures (e.g. the fabric material of Darla’s sleeves and the render quality of metals) and appreciate the switch to Redshift. However, Tim needs to be careful to not change the look too much for “normie” followers of Quest which means, any changes due to a switch in the render engine need to be rather subtle. In other words, the visual difference could be larger, if visual continuity did not have to be maintained or if the render style were less stylized to begin with.
I never really cared all that much for the layer-based material system for Standard and Physical and much prefer the node-based system that Redshift uses (depending on the intended look, it may not make that much of a difference in the final render, but it sure is different when setting things up).
Also, there are far more ready-made materials for Redshift than for Standard (which are quite useful when you need to re-texture or put materials on things) and Redshift supports PBR (and metalness workflow) which, AFAIK, Standard does not. Standard is also not a “physically accurate” render engine, which is probably why Maxon decided to add “Physical” (which is also often slower than Standard if I recall correctly—as I said, it’s been a long time).
Now, the Auroratrek movie you referenced uses what could be called a semi-NPR style with relatively simple materials/textures; the more complex the materials, the more Redshift wins. In that video, the textures/materials of the outfits are far less complex/detailed than in Quest; if Tim had tried to use high-res textures with bump/normal maps and subdivision in Auroratrek, I’m quite sure the render times with Standard would also have jumped. I’m also assuming that video does not use GI and SSS all that much, if at all. If you add those (in Physical) render times increase considerably.
What I’m trying to say is that Redshift is faster if you try to get the same render quality out of Standard/Physical. However, for a simpler, NPR render style, the Standard/Physical may have a speed advantage. It is a little like the iClone render engine and Iray; iClone renders faster, Iray looks better, but the differences may not be “earth-shattering”.
I would also not be surprised if some scenes in Quest rendered faster in Redshift (if properly optimized) than in Standard, e.g. those with a ton of instanced trees.
Finally, Redshift being a GPU render engine, scales with the GPU power and that has been, in my experience, increasing faster than CPU performance over the past years. Cinebench 2024 uses a render benchmark based on Redshift and runs on the CPU or GPU. On all my C4D systems, the GPU scores run circles around the CPU scores on the same system (note: Cinebench does not work on RTX50xx GPUs yet).
Thanks! I might be doing something wrong, but I thought that a character only gets affected by the SS if it’s first inside a Group. When I put the hierarchy just “loose” inside the SS, it doesn’t seem to be affected. I think it may be that “nesting” that puts it beyond the reach of the light. As it turns out, Nirwana might have pointed things in the right direction in the Redshift world:
Okay, I didn’t know this RS Tesselation was a thing LOL. I gave it a try, and I can already see the possible benefit that it doesn’t slow things down in the viewport like a SS tag does, but seems to do the same thing, render-wise. Also, by not having to nest the objects (as above) lights seem to able to “reach” individual objects (like the eyes) in the hierarchy, so this might be the way to go. Thanks! I’ll need to explore this some more and see if it works for me, but it’s certainly promising. I’m still pretty new to Redshift, so I guess I have a lot to learn.
Metals are definitely a big improvement–they were a total PITA in the standard materials, so I appreciate a “Metalness” slider
The nodes took some getting used to, and I’m still not sure what everything does, but I think I’m getting there. More powerful for sure, but seems a bit more complicated too.
Yes, far simpler textures, not least because I began work on it almost 20 years ago! As I noted to others at the time, one of the reasons I could attempt something like Aurora at the time was partly because the environments were mostly flat shiny surfaces and simple geometric shapes–no grass, no dirt, no fog, nothing too organic. I don’t think Quest would have been possible back then.
Yes, the “Sprite” node is pretty nice for speedier renders for objects with a lot of alpha channels.
Anyway, thanks to both of you for helping me revisit the SS/RS/lighting issue, I think this will be very helpful going forward.
It does not do exactly the same thing. The C4D subdiv gives you a choice of the algorithm to use for the subdivision. Also, you can use the C4D subdivided mesh as input for other things (the tessellation is only at render time; however, if you want to use displacement maps, it’s pretty much a necessity). You may want to check out the documentation on the RS Object tag and tessellation in Redshift to avoid a “hanging system” or wasting render time without visual benefit. I would also advise looking into the wireframe node to help you visually judge what kind of tessellation levels may be a good compromise between looks and speed (the default values are often overkill).
Again, I don’t know what the problem appears to be. As you can see in the screenshot I linked before, the entire character mesh is in a C4D SubDiv object and the eye-light works just fine.
I would use that metalness slider only if the assets you are using don’t come with a metalness map or if you are creating your own RS materials from scratch; in all other cases, a proper metalness maps is usually preferably. BTW: Characters, clothing, and other objects exported from iClone via FBX that have PBR materials should also come with metalness textures. However, these may have to be linked manually in C4D.
I was not just thinking about the Sprite node, but also populating a scene with instanced objects. If you have complex backgrounds (i.e. many polys), that need to be rendered several times/over a number of frames, I would suggest looking into Redshift proxies. For some scenes, they can (a) speed things up in the viewport (simplified look) and when rendering and (b) take up less VRAM.
Okay, thanks, I’ll look into the nuances of the RS Tesselation. Initially, however, I did a side-by-side render comparison between using the RS Tesselation and a SS, and they looked exactly the same, but RS didn’t bog down the system.
It might be working on yours because you have an RS Object tag on the Group(?) I didn’t and that seems to be an issue for me. But, no matter, I’ll use the RS Tesselation going forward.
Okay, I’ll look into this more, thanks!
I’m guessing the plants that come with C4D come in as Redshift Proxies? They do render nicely in large numbers!
But, since I mentioned the Sprite node, I did get some really great results using it for this card-based hair I recently purchased. With the help of your and Autodidact’s suggestions, I was able to work with the textures which–if left as simple transparencies–would have killed the render, but what I ended up doing was doubling the size of the alpha channel, increasing the contrast a bit, then making it a black-and-white bitmap and using that in the Sprite, and not only did it render quickly, but I’d challenge anyone (okay, not you guys LOL) to not think this was strand hair. Thanks again for all the help!
Indeed tha hair looks great!!
Nice work.
