Topics created by Cairyn

Hi, @Cairyn said in The asymmetric matrix inversion issue: I guess it depends on the point you want to make... I would mostly agree, but my point point was more the other way around. Not that shearing is a thing you commonly want to do, but the fact the you should be aware that c4d.Matrix will not enforce an orthogonal basis. Because if you thought it does, you could for example think that my_frame = c4d.Matrix(v3=my_normal) would be a sufficient way to construct an orthogonal frame where my_normal is k and then carry out some transforms with it and wonder what the heck is going wrong. @Cairyn said in The asymmetric matrix inversion issue: This has, in fact, been a point I thought long and hard about... What I meant with that passage was the story which has been attributed to many famous programmers who left a complicated piece of code only commented with "and here comes the tricky part". Usually told as a testament to both their technical genius and their communicative shortcomings. The often (at least silently) admired notion is that "everything is self explanatory for a smart person". Which of course is neither true nor very "cool". I feel you are drifting a bit into that direction. About the linear algebra stuff. In my opinion there is no wrong or right there, you can do a good job with a very coarse and with a very fine model. Although I think often the geometrical meaning of linear algebra has been neglected in teachings about it. Especially Cinema's "matrices" (which in my book do not really qualify as matrices) can be very well explained as linear maps which will automatically will make all four principal transforms intuitively clear. Everything that is left then is to explain that matrices are just another way to write a linear map, i.e. a linear combination of vectors representing a coordinate system. Cheers, zipit

@Cairyn said in Matrix and Vector access: But this is happening on the C++ side - we're practically inheriting C++ issues indirectly Correct our Python API is just a layer on top of our C++ API so it of course has its same limitation. But now you actually make me wonder how the Python/C++ interface avoids situations where the C++ side deletes objects that are referenced in a Python wrapper without notifying these, creating invalid pointers. This is exactly the purpose of C4DAton.IsAlive and internally for each type that may be null each call do perform a check to see if the referenced c++ object is still alive. The whole Python interface is, after all, a layer on top, not as deeply integrated as would be necessary to make use of Python abilities like ref counters. Or is it? It depends, because in the case of obj = c4d.BaseObject(c4d.Ocube) then the owner is the Python object, so we have mechanisms to ensure that this obj is held by the PythonObject, and in many cases, we manage python object ref-count properly, so the GC doesn't delete thing people may not expect to be deleted or don't let alive object tool long (aka memory leak). But this is just the Python Object that represents a C++ object, so we have to be careful because if a Python object is deleted, the C++ object is not necessary also cleaned, it depends on who is the owner of the C++ object. Hope this answers your questions. Cheers, Maxime.

ok, thanks for the confirmation!

@zipit said in What is Vector.GetLengthSquared() really meant for?: My major point was that there are certain programming assumptions (multiplication is better than division, never take the square root if avoidable, cubic complexity is uncomputable, etc.) that should be taken with a grain of salt due to the fact that they rely on a certain "state" of hardware. I.e. all these three do not really hold true anymore to the extent they once did. (...) That goes without saying... ultimately, any effort towards optimization needs to be checked for effectivity. Nevertheless, I was curious and abused a plugin of mine to execute some timer checks in C++, just for comparison (code excerpt only): using namespace std::chrono; Vector v(100.0, 100.0, 100.0); float f; milliseconds ms1, ms2, diff; ms1 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); for (int i = 0; i < 100000000; i++) { f = 0; // v.GetLength(); } ms2 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); diff = ms2 - ms1; GePrint(maxon::String("Time counter Empty:") + maxon::String::IntToString(diff.count())); ms1 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); for (int i = 0; i < 100000000; i++) { f = v.GetLength(); } ms2 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); diff = ms2 - ms1; GePrint(maxon::String("Time counter GetLength:") + maxon::String::IntToString(diff.count())); ms1 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); for (int i = 0; i < 100000000; i++) { f = v.GetSquaredLength(); } ms2 = duration_cast<milliseconds>( system_clock::now().time_since_epoch() ); diff = ms2 - ms1; GePrint(maxon::String("Time counter GetSquaredLength:") + maxon::String::IntToString(diff.count())); Switching off all optimizations, I get (for multiple button presses): Time counter Empty:185 Time counter GetLength:921 Time counter GetSquaredLength:228 Time counter Empty:184 Time counter GetLength:922 Time counter GetSquaredLength:228 Time counter Empty:183 Time counter GetLength:921 Time counter GetSquaredLength:228 Time counter Empty:183 Time counter GetLength:922 Time counter GetSquaredLength:228 Time counter Empty:185 Time counter GetLength:921 Time counter GetSquaredLength:228 Time counter Empty:183 Time counter GetLength:921 Time counter GetSquaredLength:227 That is far more like what I expected (double so if you consider that the loop with a constant assignment already takes 185ms). Considering that I had to up the loop count to a hundred million to get measurable results, it is practically guaranteed that any difference between GetLength and GetLengthSquared in the Python sample is drowned in the Python interpreter's overhead, and any result from my initial tests must be attributed to sheer randomness.

@m_magalhaes said in What's the state of Ngons in Python?: About the bugs on the forum, we have introduce few month ago new tags "Bug report" and "Bug Fixed". We are also adding some tag in our bug database to retrieve faster the post on the forum. I know it's not perfect and sometimes we may forgot to add this tag on the first post of the thread. But it's better than nothing. Yeah, I'll try to use that in the future although it probably won't affect existing threads (a lot of valuable knowledge still resides in the "old forum" parts). @Cairyn said in What's the state of Ngons in Python?: Anyway, I don't think this issue is of huge interest as you said there's a replacement in the new kernel already, which will probably come with a diferent tesselation algorithm, so I present it here as a curiosity. Don't get me wrong, all modeling command have been migrated to the new modeling kernel. If you are using SendModelingCommand, it will use the new kernel. So what you see now in S22 and R23 (ok you will see in R23) IS the new kernel. There will be no better tesselation. I consider this as a bug. As a Perpetual user, I'm still on R21 (as tagged) so is this also the new kernel? AFAIK the new kernel has been working behind the API for a while now, being gradually introduced into the functionality, so it's possible that this bug still persists. I can't test it on a demo of S22 for you, as the current licensing does not allow me to install one. The new modeling kernel isn't exposed yet. But it is used. I understand, it's a bit confusing. We are moving Cinema4D to the new core. But as long as some part of Cinema4D are using the old system (object manager for exemple), the new core need to "translate" that to the classic API. (...) I hope it's clear. Sure, I have a few decades of programming under the belt. It's just a bit difficult as non-Maxon developer to see the details. Seeing only the API (and therefore the user-side of the translation layer), I can't always tell what the underlying data model really is; what's stored as attribute, what's calculated on the fly, what's internally cached for fast access, what's abstracted and what's plainly stored... I may make wrong assumptions on the internal workings. this look like a valid ngon but i will ask :) It probably is valid - I don't see a reason why it should be forbidden. I just notice that the tesselation algorithm tends to avoid such "inner polygons". That may not be intentional (based on a rule) though, but just a consequence of how the algorithm works. Thanks again, -- Cairyn --

yupyup, BaseSelect has no connection to the original object it actually selects from, not even in the cases where you get a pointer to the BaseSelect returned and change the selection directly through it. That's why we need the max parameter for SelectAll and ToggleAll -- the BaseSelect doesn't know what "all" even is. (Not GetLastElement()!) For GetRange() though, that reasoning does not apply. Now let's see whether I can crash C4D with inconsistent edge selections...

Hi, jeah, that is probably somewhat the reason. Although Python has true statically typed arrays, which also can be used to directly in-place manipulate C arrays (i.e. array.array), from what I understand it is quite cumbersome to achieve such linkage. This is probably the reason why Maxon does not bother in this case and others like for example vertex colors. Including these access points is still a bit puzzling though. Maybe they are somehow used internally? But I cannot think of a case where this would make sense. Cheers, zipit

Thanks. In the meantime I made some more experiments, and it seems the problem is limited to when you click Execute in the Script Manager or the Customize Command window. I created a keyboard shortcut and embedded the script as icon in the GUI. In both cases, the status bar gets correctly updated regardless of what window was active / received the key press, and where the icon resides (same window, other window, undocked toolbar). It seems the Python interpreter is not blocking the message loops in these cases. That makes the question somewhat academic, because shortcut or icon (or menu but I did not check that) would be the common ways to start the script; starting it from the Script Manager is common during development but irrelevant in practice. I'm curious to hear what the developers will say about the message loops though.

@m_adam Thanks for the confirmation! (I swear I'm not doing this on purpose...)

@m_magalhaes thanks, that'll do!

This is fixed in R23. Cheers, Maxime.

@m_adam okay, good that it's found... I guess I can go with the code above for now that excludes tags explicitly and gathers them in a different recursion. As per the original issue (there is no function in the API that returns the currently visible tracks in timeline n), I guess I would need to make a requirement/suggestion on Maxon's site? Or is something like this planned already?

Hi Cayring this is indeed a bug I'm going to report them and fix them (both for BaseMaterial and shader) as soon as possible :) If you have other cases like that please report them. I set the topic as solved, I will bump this topic once the fix will be available. Cheers, Maxime.

@m_adam Thank you for the confirmation and the reading suggestions. Just for context, this is a general conceptual question and not connected to a specific code issue. I noticed the behavior while doing some test scripts with id() and is. It is worth noting that these Python properties need to be used carefully in concert with C4D objects. (I wouldn't exactly recommend using pointer comparisons in C++ either ;-) ) I will include an "advanced" chapter in my Python/C4D book to mention this.

Thanks for the confirmation. I shall treat the extra link directions as nonexistent then ;-)

Thanks, it's good to know that there are internal functionalities actually using these flags!

@m_adam Thanks for the info! I knew I was still missing a few flags ;-)

Yes, C4DAtom.CheckType() in Python. Thanks for the confirmation, it bugged me that it was only in the Python doc but not in the C++ doc.

Hi @Cairyn thanks for spotting it out, it's an issue in the python documentation, if you take a look at the C++ documentation it's said that it supports only Objects and Tags (see BaseDocument Selections Manual). (I will fix the Python doc) On other hand, I confirm to deselect all objects/tags the best way is to call SetSelection with None/nullptr. And finally, as zipit said, in the end, it's only a wrapper around BIT_ACTIVE with the benefic of GetSelection, that the selection is cached so you avoid the iteration on the whole scene. Cheers, Maxime.

@zipit said in How to handle C4D Unicode in Python scripting?: well, that API object names thing is a flaw of Python 2. So working as expected or not as expected is a bit a question of the point of view. If you got the string passed from any other source the problem would be the same. Right. The main thing is to understand the issue, and then to write the chapter in a way that explains what to watch out for. (I do wonder how third-party modules would do with a name string passed to them from a script that reads them from the API... well, another bridge to cross another day.) Python 3 clearly is superior in that respect, as there is no unicode class and all str objects are unicode (what they appear to be already in C4D, but with matching len, index, and slice capabilities). On a more productive note: I think that focusing in Unicode strings isn't really that important for Python stuff in c4d, since object names should be something you largely ignore as they are a unreliable source of identification and only are rarely important in other contexts. Hmm, I am not sure whether I would agree to that. Good naming is essential to find your way through complex scenes, and a good naming schema can be built in a way that is friendly to string search and comparison criteria, esp. if you can build your own scripts to perform the search and selection. I just point at the _L _R naming schema for joints that is common in C4D's docs. Of course, if your objects are all named Cube, Cube.1, Cube.2, Cube.3, then name-based identification may be unhelpful Anyway, I am not the person to judge that, as I am only teaching Python to interested users. What they do with it is their own decision; I just have to point out the crucial points so they can apply the code to their own concepts.