MighT

Hi Cesar, nice! Do you intend to share these on GitHub or alike? I'd happily contribute for example with Python 3 adaptions. While my French is virtually non existent, I could also try to contribute translations. And is there any kind of license or are there any restrictions for the code shared? Happy New Year!

My feeling is, Maxon may have withdrawn the .115 due to issues on certain systems (unfortunately I can not check, as my C4D is updated already and I'm too lazy to revert to an earlier version to see if i could still get the .115). I'd rather stick to the version delivered by Maxon, than using anything else. This in combination with Christmas could also explain the strange communication about this update.

@Igor Thanks for the info. Though I'd wish there were some other plan than a Wiki. From very few exceptions I have not yet seen any functional Wiki, which did not degrade to a ridiculous mess within a very short amount of time. Usually the time needed to maintain a Wiki properly does not and can not be invested. No single person will be able to accomplish, what the community will not provide (and communities provide only the interesting stuff usually). A Wiki without maintenance usually falls apart quicker than Maxon can say subscription... For me such threads in combination with a few tags (already there) and a working forum search (also already there) would be enough. Anyway, thanks for the info.

Hm, this is a legal site? Looks pretty dubious to me. But anyway, you got what you needed, so I guess, that's good. And I perfectly understand your need, as I just checked my maxon.net account and there under downloads it is still 25.113... 😞 On the other hand my C4D as well as my Maxon App properly offered the 25.115 update to me. If I were you, I'd certainly contact Maxon, because something seems to be off with your license/account there. You certainly deserve, what you paid for and shouldn't need to fall back to mysterious "3rd party providers".

Actually, even if disabled, the Quick Start dialog should still open, when an update is available. At least here it does so.

Maybe the title of this topic could be changed? Because from what I read here, there is no general rule for topology and cartoon shading. And how could there be one, given the vast variance of toon styles. Except maybe the one rule, that topology may be arbitrarily distorted to achieve certain effects. For me, being neither an artist nor a modeler, it would be more interesting to see this topic being discussed more generally. Like, what kinds or types of topology can be used or can help with achieving certain shading effects. Much like those guides describing good (in terms of animation or SDS modeling) topology. And much like Hrvoje did so fantastically in his Vertex Pusher modeling tutorials. But don't get me wrong, I know, this is a lot to ask for. But I think, if such a thread is named correctly it can be a good starting point for a collection of small tips and tricks in this direction.

I did not want to imply, comparing Blender and C4D would be unfair. Both are DCCs and can of course be compared. I only meant to try to compare the manpower or number of developers directly is in my opinion not possible in a fair way. Or at least be very difficult. Especially when trying to do so based on some chart about Blender or hearsay about Maxon internals.

Hm? Actually I prefer not be drawn into (as Cairyn would say) "one of these threads". Also I'm not sure, which insights I'm supposed to share. I assume, I'm being asked as developer and not as a former Maxon employee. So I will keep it more general. From my point of view onboarding new developers is (or at least can be) a difficult task. It almost always takes quite a bit of resources (aka time of already experienced developers) for a significant time. Every developer is different. And like all humans every developer learns differently. Can bug fixing be a good learning path? Yes, I think so. If you have a tenacious and masochistic type of a developer, this can work out great. I do not mean this in any bad way. Maybe in other words, you need somebody with a lot of will to reach the goal. If you have someone with such characteristics, then the result can be awesome, because the knowledge collected on the go is immense. On the other hand there the "this baby has to run as quickly as possible" type of developers. For those a smaller or simpler starter project can offer a better learning curve, as they have better chances to reach the needed feeling of success to keep them going. Also bugs are pretty human in this regard. Every one is different (I hope, now I do not get drawn into a discussion, how theoretically many bugs are identical) and like with humans you can't really judge it by looking at its cover. So it can already take quite a lot of work from an experienced developer to judge, if a bug is suited to be worked on by a beginner (usually you want "isolated" bugs, where the fix has little potential to influence or break other stuff). And afterwards you need an experienced developer to check and verify the fix of the newbie. This can lead to a situation, where it costs more resources than would have been needed if the experienced developer worked on the bug in the first place. I think, comparing Blender and C4D in this regard is misleading and probably also a bit unfair. Open source in a way is way better suited for onboarding new developers. Of course a) the code base is open, so chances to get somebody, who already has some experience, are better. And b) there's a kind of playful flavor in the process, which you usually do not have in closed environments. I do not want to say either way is superior. It's different and the difficulties are different. I don't think, it's a good idea to transfer the paradigm of either to the other. And of course either side can also learn from the other, but chances are the result of such learning process or evolution will not be identical to the other side you started to learn from in the beginning. The constraints are too different to end up with an identical result. I could go on talking for hours about this, but as I said in the beginning, I'm not even sure, what I have been asked for. For example the topic, how many interesting ways there are to make even the best developer have merely no output at all. Although I tend to like the view from the other side a bit more, the many ways you can get productive output from bad developers (or as I would put it, there are no unproductive employees, only employees used in wrong ways). Or the topic of team mindedness of developers, something my breed is probably not really the best in (which on the other hand is most likely the reason, they got developers in the first place...). Just to be not completely off topic: I see nothing wrong in a service pack focusing on bug fixing. And I'm a bit irritated, about certain views for example about the number of bugs in "UI change" release. To me it's pretty obvious, even if there were no features to present, there is way more work going on than visible at the surface. Please, do not misunderstand this, I'm not interested in another discussion if R25 is a release worth its money. Or if the communication strategy is right or wrong. Or Maxon's business strategies. In my view Maxon tries nothing less but rebuilding a skyscraper from scratch without scratching the old facade during the process (better: with as little scratches as possible). Or trying a heart surgery on a living walking human without any support machinery. Not many companies have even dared to try this. For this alone they have my fullest respect. It's even worse for them. Their customers grew used to one of the most stable and backward compatible software products (not talking about DCCs but software in general) out there. And for such an endeavor this luxury turns into an immense burden. Whatever you do, somebody will always be pissed (even worse, most likely rightly so). And I doubt, many can imagine how different, how much more complicated and how much more time consuming this is compared to building something new from scratch. Maybe not even all developers at Maxon did foresee the complexity to its full extend (which is no critique). I mean, hell, I live in a country, where we are not even able to build an airport from scratch anymore. Something which has been done thousands of times all over the globe. Complexity is a bi... and forums can be a bad place to discuss complex topics. Most humans are not interested in understanding complexity. We usually prefer the simple, black/white answers. And, again an example from the country I live in, people can get pretty angry and even violent, if the answers to questions which frighten them are neither black or white (yep, talking pandemic here). I think, same patterns can be seen in the C4D discussions since a few years. Understandable. Inevitable. Certainly not constructive or helpful for anybody. Sorry for being carried away. Probably another reason, why I shouldn't be pulled into threads...

I know, it would be only half the fun and probably everybody knows anyway, but just in case. There's a dedicated bar chart node and a csv import node ("Import Data"). They may be R25+, though.

Bold type, exclamation marks, two word sentences... and you are surprised?

@Cerbera Beautiful works. Given these clubs are curved in various directions, may I ask a few technical questions? What precision are you being asked for for these surfaces? How is this precision specified? And how is it verified? Or is it "just" (please don't get me wrong, it's in no way less impressive) modeling along imported CAD data? And along these lines, does anybody know of a tool/plugin, which is capable of correctly comparing a poly mesh to a mathematically described free form surface (aka CAD data)? I do not mean comparing to an imported poly representation of the CAD data. I'd guess at least car manufacturers would have something like this in use? In my mind the result of such comparison would be a vertex color map containing the actual deviation.

Very nice! And I praise you for not having them on Instagram. Much appreciated. May I ask, do you create these procedurally or simply by brute force manual finetuning? And are these dynamically simulated? Just interest, they are stunning either way.

I guess, the question is to have this functionality as a simple toggle command that could replace the "Enter" key assignment. Just like Cairyn's solution.

In its simplest form such a script would be just a combination of SendModelingCommand() with MCOMMAND_CONVERTSELECTION to convert the selection and CallCommand() to switch the mode (command ID can be found in Script Log). Right now, I'm in a hurry. Pretty sure, until I will find some time tomorrow, somebody will have copy/pasted something for you. If not, please ping me via PM and I can do it for you in a few minutes.

Ok, now I did take a look at the scene file. To be honest, I am surprised. I even went back into R21 to double check this behavior is neither new nor a bug. And I am really not sure, why I have never noticed this before. Or maybe I have and forgot about it again... Anyway, what I said in my last post is only half way true (I prefer the positive wording, but of course it was equally half way wrong...). While the Object node is agnostic to the object type, it does indeed not update its ports (or rather the availability of these) depending on the type of the Object passed into its Object input. You are right to create Object nodes from "similar" object types. I somehow still can not believe it and would have sworn this worked, but obviously it doesn't. 😞 After loading your scene here, the outputs of the "settings Null" referenced inside the Xgroup did show undefined outputs. I assume they broke, because either the User Data changed somewhere during building the scene. And even more strange, I was not even able to access the port lists of the Object nodes inside the Xgroup. So I rebuilt your Xpresso setup from scratch and it worked, maybe even the way you intended, but I can't judge without knowing the actual goal. Question: Why do you need to pass Object references into the Xgroup? Wouldn't passing the parameters and global positions into the Xgroup work equally well? At least this should salvage all your issues. And lastly lessons learned: In order to have full and correct parameter access in Object nodes referring to varying objects via their Object input, they indeed need to be created from the correct object type. Accessing anything but most basic parameters (well, mostly PSR, basically everything from Basic and Coord. tabs) one has to be extremely careful with the setup in order to not break it. Especially because Object nodes seem to be able to break in a non-repairable way, leaving replacing them with new ones as only option. Double caution in above scenario, if User Data is involved. My feeling remains, this has worked in the past and still hope for an Xpresso guru calling me stupid and telling us about the magic checkbox we have overlooked here.

In general your approach is correct. (You do not even need to have "similar" object types. Wrong, please see following post) The Object node is agnostic to the object it represents. Of course there are limits, e.g. when feeding a different object type which does not have a certain parameter used in the respective Object node. I did not have the time to check your scene, yet. Though in your screenshot the disconnected outputs of the Xgroup immediately catch my attention. But I guess, that's too obvious and probably just an issue of the screenshot. Another thing is, are you trying to scale a Joint object? Is this joint part of a joint chain?

Sorry, I was confused about R23 release date. My bad, especially this being a delicate topic.

Or for those interested in awesome Lego constructions. 🙂

Unfortunately I had met ZZ only shortly before leaving Maxon. He was among other things packaging releases, making sure documentation and translations were complete. Making him actually quite an important piece of the puzzle for the end product. He was certainly one of a kind and belongs to my dear memories of my time at Maxon. See you on the other side, ZZ. RIP. Spoiler alert, select text to see: Type ZZ into the commander in latest releases of C4D (didn't check, but should be in S24 already, if not R23, too).

I agree with Noseman. And I'm a developer (at least so they said)... feel free to contact me via personal/direct message. But please, rather don't, if you expect me to create your money maker for free.

While Cerbera already told you, I'd like to add, that you wouldn't need to know. There is an "Import Script" command in the menu of the Script Manager, which does the trick for you.

I'd say an uploaded scene would be more beneficial than any video. You could strip it down to just objects with Xpresso tags, if needed for size or legal reasons. And on Maxon Labs they had a plugin, which was able to scan your scene for C.O.F.F.E.E. usage. But it looks like Maxon Labs is gone (as announced before) and some of its content went into Cineversity. Yet, this is not true for all content and especially I did not see the plugin I'm talking about here. But I may be blind or it may be a matter of time. I don't know, neither if you had access to those plugins in Cineversity. To our community: Please, lets not make this thread into another "Maxon is evil" thread. It's not needed, the topic has been discussed in all detail in all appropriate and non appropriate context, there's little chance of new insights by repeating over and over again.

Do you want help with a script or are you looking for somebody to do the script for you? In the latter case you can contact me via private message. If you are only looking for help, it would probably be a good idea to post, what you have already.

I'd probably do it the other way round. Instead of trying to get a certain layer and finding out which objects belong to it, I'd iterate over all objects, using GetLayerObject() to check, if it belongs to the relevant layer (in the end in your case, it shouldn't matter, which layer it is specifically, as you are only interested in the visibility flags).

I think, at the moment it would be more a (simple) Xpresso approach. Scene Nodes a) can not directly influence legacy objects (lets ignore Capsules for a moment here) and b) I do not think, I have seen a camera object in Scene Nodes context, yet. But I guess, seeing you are still on R20, you asked for Scene Nodes out of interest, only. Xpresso will get you there smoothly. If you are an Xpresso beginner, I'd start with "Set Driver"/"Set Driven" to set up the basic connection between the parameters. If I'm not mistaken, Range Mapper nodes will already be created with this approach. So you will in the end only need to adjust these range mappers.