I don't think either adding Eevee/Cycles support based on the current separate node types, or using OSL script nodes in the existing shader nodes is the solution. It still makes the shading nodes somehow foreign to Blender.
If the cyclic curve is divided by 2 points into 2 segments, from with equal positions of the points, the segments will be of length 1 and 0
why between 0 and 1 we have length 0 ?
More precisely, how to determine which part of the curve will have length 0 and which part 1?
Maybe it's not considered a bug, but from a user's point of view it's clearly a limitation :(
why between 0 and 1 we have length 0 ?
Not sure how to remedy this as this is the current intended behavior as the start and endpoints are equivalent reducing the curve to a single point (see image below). While the behavior may be unintuitive when passing 0.0 and 1.0 as inputs these values do represent the same point on the cyclical curve but it is consistent with any other point on the curve (since input is clamped to [0.0, 1.0]).
It's not a bug. The transformation does not convey the angle, but how the mesh needs to be rotated to have this angle. While more detailed information is not available. The plan is to solve this Quarterion sockets
Just so that it is not forgotten, the wiki page will need to be updated as well: https://wiki.blender.org/wiki/Building_Blender/Other/BlenderAsPyModule
Fixing a typecast that seems to only work on Windows...
I'm not marked as a reviewer here, but since I've been working a lot on making mesh data structures more generic and SoA-like recently (T95965), I have some thoughts about the abstractions used here.
I'm concerned with the structures like MeshVertex, MeshUVVert, MeshEdge, and MeshPrimitive, mostly because they are more of an array-of-structs layout which we've been spending a lot of time moving away from recently, for both meshes and curves.
- Merge master
- Constants in class fields
Hi @Brecht Van Lommel (brecht) . I get where Blender is coming from on wanting this to be better integrated into the existing node system. As we discussed in the rendering meeting, part of the issue with integrating MaterialX to work closer with Cycles and EEVEE, is the nodes in MaterialX sometimes being "lower level" than Blender nodes. And them being hard to mix. BUT, MaterialX can export GLSL or OSL code, which potentially either renderer could use.
Thanks for the patch. Before Blender developers can start reviewing this, we will first need to agree on the design in T100894: MaterialX add-on.
Updated to the current state of master (changes in text.c)
It seems, that mesh caches are rebuilt for every frame, but have to dig deeper to see if this works as intended and if it could be optimized.
So is the point you're making that while switching the deps graph update ordering here fixed the bug I'm seeing, the fact that the graph is not already up-to-date implies a bug _elsewhere_ in another operation that should be triggering an update, but isn't?
Also, while the attribute does not know that it is a single, it is impossible to check the correctness of the code. I hope that I'm not mistaken, it may be that someone will correct the spring evaluation of a single attribute as a field and a report will appear on incorrect curve adaptation)
Timer 'grain size = 1024' took 2.1 ms Timer 'grain size = 2048' took 1.8 ms Timer 'grain size = 4096' took 1.8 ms Timer 'grain size = 1024' took 0.6 ms Timer 'grain size = 2048' took 0.5 ms Timer 'grain size = 4096' took 0.5 ms Timer 'grain size = 1024' took 2.0 ms Timer 'grain size = 2048' took 1.8 ms Timer 'grain size = 4096' took 1.8 ms Timer 'grain size = 1024' took 2.6 ms Timer 'grain size = 2048' took 2.5 ms Timer 'grain size = 4096' took 3.4 ms Timer 'grain size = 1024' took 0.9 ms Timer 'grain size = 2048' took 0.9 ms Timer 'grain size = 4096' took 0.9 ms Timer 'grain size = 1024' took 2.6 ms Timer 'grain size = 2048' took 2.4 ms Timer 'grain size = 4096' took 2.5 ms
According to the test results, I can say that 2048 will be the best. It starts to show up at 3.6~million grids. Yes, 2.4 milliseconds - 200000 cubes and constant overwriting (true all the time)
Hey I was working on screw edge for testing and I realized the center parameter is in global coordinates, which might result in improper testing as the newly generated mesh after the operation is applied will be different depending on the position of the mesh, which could change as new operators are added.
I think this is going to give many false positives for users. Someone using latest master shares a .blend file online, and then everyone using the official release gets a warning while most of the time it will work fine. Worst case, this warning message becomes so common that users start clicking it away without thinking and all we've done is make the UX worse.
I think it would be a lot helpful to take a step back and write the proper proposal. It is important to have the design description, mental models in place. A lot of questions will be naturally answered by a good design document.
That's interesting. Are there any modifications to the parent object between the operator begin/invoke and the call ED_object_parent_set ?
Here is the most minimal repro steps I've been able to come up with. Note that it is very sensitive to the order of operations, and I don't totally understand what is going on under the hood.
This was fixed between 2.80 and 2.81.
@PAKAN (soccer-20041) I'm sorry, I do not understand your question. Do you still see the error when using blender_factory_startup.cmd?
For the record, after trying to mitigate some string issues in D15996, a talk with @Hans Goudey (HooglyBoogly) hinted at the possibility to replace BLI_sprintfN() with fmt::format(), which is already used in Blender and could be generalized to more C++ code for this purpose.
Perhaps we could have one shared shading system per device type?
I also wonder if this works with CPU + GPU render now, or if we would need multiple shading systems for that?
Right, CPU + GPU didn't work. I've changed it to use one global shading system per device type now, which works with CPU + GPU. Was hoping to be able to create/free them in ccl::ShaderManager::device_update to avoid having to keep track of the device in the shader manager, but unfortunately that doesn't work with custom OSL scripts that are loaded before that (and need to be loaded into the shading system for every device type). So ccl::ShaderManager now saves which device it was created with.
Also can confirm this crash on Windows10/RX570.
Saw this is a duplicate of T101372 after I found out the issue is with world shader.
@Hans Goudey (HooglyBoogly) Am I understanding you correctly that in the long term we want all modifiers to implement a single modifyGeometrySet?
Lucky and the formatting actually kept it on one line
As I've mentioned before, consolidating modifiers and making more things go via the geometry nodes is a very nice goal. Avoiding code duplication is another good goal.
There are many ways to achieve the both, with the different strong and weak points. And this is part of a design task to make it clear why the achieved goal is outweights the downsides of the change.
Then I'll update now.
This looks like a nice improvement. Two comments:
- 1024 seems like a small grain size for editing a boolean array. I'd probably go with 4096 so we don't use threading unless it will really be worth it.
- adapt_single_to could be simpler (probably doesn't need to be a separate function) if it used attributes.domain_size(to_domain).
Agreed with @Leon Schittek (lone_noel)'s comments here. Otherwise, thanks for making the patch!
Needs a merge from master and the commented out code has to be removed. Other than that, looks good to me now.
Thanks, will try this :)
To me it seems much better to commit to the better/simpler design of limiting what is allowed to to in update functions. That can be documented as necessary. But complicating the core design to support this sort of thing doesn't seem worth it.
- Merge branch 'master' into temp-geometry-viewport-preview
- add show viewer attribute checkbox
- add Viewer Node option to View menu
- fix hiding outline in curves sculpt mode
- improve overlay drawing for curves
It's not perfect but you could set some flag to true in the update function and then just check that flag in a timer so that it only syncs the tree when necessary. I'm not sure if there is a perfect solution for this scenario currently.
@Paul Kotelevets (1D_Inc) Can you share that geometry in a .blend file?
@Aaron Carlisle (Blendify) is this ok?
- Revert changes in BKE_fcurve
- Don't show speed factor when retiming tool is used
Just to update, as I went through the rest of the explanation text, I saw some more mismatch. Please rewrite the page, following examples closely.
Do you mind splitting cleanup from functional changes
- Use custom data type instead of FCurves
- Fix empty keymap warning
Yes. A very old problem. I'm not sure if there is already a report on nate, so as not to be duplicated.
Good morning Philipp,
updated patch so it applies against after https://developer.blender.org/rB125ac1f91433
Ah! So if I change the code to do it in that order, then both the crash and the error in my test are resolved.