text:
Set emission strength with alpha port of image texture node?
I encoded the colors and brightnesses of stars in the pixels of an image texture. The colors are in the first three components of the pixels' (r,g,b,a) arrays. The brightnesses are in the fourth component (a).
I subsequently connected the Color port of the Image Texture node to the Color port of an Emission node. (See image below.) It worked and the stars have the appropriate colors.

I also connected the Alpha port of the same Image Texture node to the Strength port of the Emission node. My hope was to use the alpha values to set the relative brightnesses of the stars. This... doesn't seem to work.
I did a test in which I set all the alpha values to 0. This would correspond to an emission strength of zero, which would make the stars dark. Yet, despite the alpha values being zero, the output of the Alpha port seems to be nonzero, since it makes the stars very bright.
So I'm wondering—what exactly is the output of the Alpha port and should I not use it to encode emission strength? Why would it output any value other than the 0 that I encoded in the (r,g,b,a) arrays of the image texture?
Many thanks in advance for any help you can give!
EDIT: I'm noticing now that the alpha values in my image texture affect the emission strength when the two nodes are connected via the Color ports alone. This seems strange, since I expected the Color port of the Emission node to accept only the emission color, not its strength.
The other possibility is that it's the transparency of the emission color that is being affected so that lower alpha values make the star look dimmer. However, when I disconnect the Color port and try to set the Emission color manually, setting its Alpha value to zero has no effect.
Confused! Any light shed on this would be greatly appreciated...
EDIT: Added screenshot of simplified node setup.

It would help if you could share some screenshots of your nodes, image, and results.

can you share that image or an equivalent one so we can try the same?

I would love to, but the image texture (which I assume is the one you need to see) is generated with Python code, and I sadly don't know how to save it to an external file to share. I assume that the image is simply packed with the model—maybe if I look in the Textures folder of the model? I'll upload it if I can figure this out. Thanks for bearing with me as I feel my way around in the darkness :D

One issue could be that your Combine XYZ is set to X (generated by dividing by the number of pixels) and '1.0' for both of the Y and Z coordinates. The thing is that [x,1.0,1.0] in on the boundary of the image (since each coordinate runs from 0.0 to 1.0). Try simply changing the 'fixed' Y and Z coordinates to 0.5 and 0.5 respectively. This will place the vector coordinate right in the middle of the row of pixels. As it stands you are picking the pixel position at the very edge of the image space and this will be confllicting with the 'Clip' (since it's on the clip boundary) and interpolation.


text:
I sculpted a plain, but I can't texture paint it
I sculpted a plain for an animation, but when I try to texture paint it nothing happens.

I tried UV unwrapping it, but it still won't work. How do I paint on it?

Texture Painting in Cycles is a bit different. You cannot just go in texture paint mode and start painting it. To start texture painting,

Select the object you want to paint on and unwrap it.
Give it a new material. Make it diffuse.

Go to Texture Paint mode and create a new paint slot. Change it to 'Diffuse Color'. In the pop-up menu, change it's dimensions to the dimensions of the texture you want and select the base color. Click OK.

Start Painting!

This youtube tutorial might also help you.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Texture painting with images
I am trying to paint grass onto a plain, but the only way I can paint with that image is if the plain is textured with the image of grass I'm using.

Check maybe here: https://blender.stackexchange.com/questions/76389/normal-map-when-painting-in-blender/76395#76395

If you set the image as a brush texture and use Stencil as the mapping option, you can drag the stencil image in the viewport to line it up with rmb, rotate with ctrl-rmb, scale with shift-rmb and paint through it to the iamge texture on the object.

Could you be more specific?

Not really - use your grass texture as an image brush and use the stencil mapping in the brush controls in the tool bar. Move the image in the viewport with the rmb and paint to put the grass where you want it without having to use the old clone from texture slot method.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Boolean modifier flickering between difference and union?
So I am creating an animation for a drill string for an oilfield representation and when I set the drill string (cylinder) to follow the bezier curve for an animation and then set a Boolean modifier on the ground (cube) the cylinder flickers from difference to union as if its trying to use both options at once, I have tried inverting and resetting normal's and removing doubles but no doubles were found and the normal's didn't fix the issue. I cant find a way to upload my .blend file so ill try to use pictures best I can. The first picture is the path of the drill string. The second picture is the Boolean modifier working properly. The third picture is the Boolean modifier not working properly and it flashes between these two. Any help or solution is welcome, thanks.

The dimensions of the models are quite large. Does scaling them by less than 0.01 and bringing them near the origin help?

Unfortunately it made it worse so I made a new file all together and it still didn't work ad I am having the same problem.

Did you try to move the curve slightly away from the plane? Another idea is enabling Full Filling at the curve's properties.

Yes I tried moving the curve slightly off the face and it did not work but something I have noticed on the new smaller version is that it only glitches during a certain segment of the animation, I will add another screenshot and indicate where it is glitching, I tried making the curve smoother and that didn't help.

Sorry, but I don't spot the issue in the last picture. Can you please share the blend file?

How do I share the blend file. I tried to find a way earlier but couldn't.

Have a look at this: https://blend-exchange.giantcowfilms.com/help/

The file has been added below the pictures.


text:
Precision of Math Node?
To normalize the position coordinates of particles for an Image Texture node, I have to divide 1 by a very large number (119,617). After running some tests, I see that the colors of my image texture are off by a factor of about 1e-4 (0.0001).
This has me wondering: how many decimal places does the Math node retain in its output?
I've noticed that some fields (e.g., the values for a Divide operation) accept up to three decimal places (and that everything beyond that third decimal place is simply rounded up or down). Is the same true for the output of the Math node? If so, is there anyway to change the output precision so that I get at least 6 decimal places in my output?
Many thanks if you know the answer and care to share it!
EDIT: Jaroslav pointed out that color is shown in the Data-Blocks view of the Outliner panel with six decimal places. However, when I look at the same view of my outliner, I see only three decimal places. Compare my screenshot (below) to that posted by Jaroslav. This is under Blendfile Data > Images > StarCol > Pixels.

Is there a reason for this difference? Am I looking in the wrong place in the Data-Blocks view? Can I trust that under the hood the full RGBA color values are being used (at least to six decimal places)? I would post this in a separate question, but as I'm only asking for clarification, it seemed best to do it here. Thanks again!
EDIT 2: The Python output for the pixel color values, on the other hand, has far more decimal places than just six! I assume that the values shown in the Outliner panel and in the fields of the Math node are shown with three decimal places for conciseness only? It would be disappointing to have the full precision stored in the Blender file and not using it!

The UI shows rounded values for practical purposes of displaying a large number in a limited space, that doesn't mean the values are rounded internally at render time

Thank you all for commenting! I just learned a few very useful things and started thinking about some important matters, like how numbers are represented and handled in Blender, and how to avoid running into issues of precision when I eventually start working with millions of particles. Thanks!!

The numbers that you see in Python console may not be precise. They are approximations converting back from binary to decimal numbers. There is no more precision, there are only more digits that at some point start to differ from the original value that needed to be stored as binary number that could not fit into the 32 bits because it was an infinite sequence for example.

I was rendering into 32bit .exr, maybe that's why in my screenshot there are more decimal places displayed. In the console you can take seriously 7 decimals, the rest is not precise.

For values Blender uses IEEE single precision floats. This gives a precision of about 7 decimal digits. The displayed value is rounded to 3 decimal places and the displayed value when editing the field to 6 decimal places (probably because the precision limitations).
The RMB value viewer in image editor of render output is rounded to 5 decimal places, but render values will render in full 32bit. Stored and rounded in format you choose.
It is also unlikely you are experiencing limitations in floating point representation:
$1/119617 = 0.000008360015716829547 $
When rendering this and storing with 32bit .EXR you get:

A sampled value of 0.00001 in Image Editor (5 decimal rounding), a value of 0.000008 in Data-Blocks outliner view (6 decimal rounding):

And value of 0.000008360016181541141 that is saved in the file by inspecting it through the console:

That's an error of 0.00000000000046471159
All of these cannot explain the 0.0001 error you are seeing. The problem is somewhere else than in precision of Blender math or your math is more complicated than what it seems and your floating point limitations snow-balled into the 0.0001 error.

Thanks for the thoughtful reply! I learned at least three things from your post. I honestly don't know where the error is coming from—strictly wondering if it could be the Math nodes. Part of the problem has been that I don't know how to check the values of things in Blender. Knowing that I can use Python code and the Outliner panel for that will help!

Inaccurate. Rounding of stored values of Math node has nothing to do with decimal places it's only displayed that way. Values of the node can easily be checked by creating a Math node in the material of the first material slot of the active object and typing: 'bpy.context.object.material_slots[0].material.node_tree.nodes['Math'].inputs[0].default_value' into the Python Console. A value like 0.0000000008 will be stored as 8.000000106811456e-10.

@MartinZ I am glad you checked that with console, but it's not that easy, you were lucky with that number. This is pandoras box - if you input 0.5555555555 you get 0.5555555820465088 back. Usually the error is on the 7th decimal place, sometimes on the 6th. Looks like rounding but its weird, because its not consistent. When you click the inputted value in the node to see it and then click away you get 0.5555559992790222, which is another weirdness and still not even Decimal(0.555556). I guess the devs know about artifacts after 6th decimal place and that's why you get that in the UI.

@MartinZ I tested this before writing the answer, but decided to omit this to keep my answer simpler. My findings were anything after the 6th place cannot be trusted and it looks like rounding with some noise to it. If anybody has explanation why this is, I'll be happy to find out.

I believe this is because of decimal to binary conversion. If there are more digits in the number before the decimal it changes things up as well. As I understand there are many different ways to store floats, maybe the one used here is not that efficient or maybe these are not full 32bit floats. I guess without looking at the source code it will be hard to tell. In any case it seems it's a precision error. Not much context was provided, I think it is likely that the error gets multiplied somewhere in the process. It seems there is not enough information to reach any definite conclusion.

Anyway, it's good to know there is a problem here and results of node maths cannot be blindly trusted.

Jaroslav, I'm curious: how did you sample the pixel color in Image Editor? I'm sure it's something simple and obvious, but since I don't know it yet, I could stand to learn it. Thanks in advance for clarifying, if you can!

If you have a moment, I posted a related question to which you might have some insight... https://blender.stackexchange.com/questions/116311/decimal-places-in-rgba-values-of-python-generated-image

@Alex You right-mouse-button (RMB) click the image in the image editor, it samples the values under cursor, like eye-drop tool would.

The quantisation issues are a byproduct of the nature of the float encoding. The accuracy is a sawtooth pattern because as the mantissa moves smaller, you lose accuracy until the next step in the exponent value. This leads to values that may be more or less precise depending on how they survive the encoding to 32 bit float. Assuming EXR here, of course.

Float data in blender are stored as 32bit floats:
The reason that you see third decimal place is that blender round float value in widget, but not in memory:

Awesome—I'm cool with having the nodes showing only three decimal places if under the hood we are preserving the full number (or at least a few more decimal places beyond just three). Thanks!

There is no way to change the precision of the values. They should be 32bit floats. I think the problem you are experiencing is not precisely about decimal places. The way I understand it, it is about binary precision. Numbers are stored in binary and a lot of finite fractions in decimal format can only be expressed as infinite fractions in binary for example decimal 0.1 will be repeating infinite fracture in binary: 0.00011001100110011...
so it will actually be stored as an approximate value. The actual way numbers are stored is more complex than it seems. You can search for something like '32bit float' to find out more about it. However the problems with precision remain.
You will have to come up with another way to do what you are doing if more precision is needed. It might be useful to post another question describing what exactly you are trying to do when you face this issue. The solution might be possible at another point in your workflow.

For sure I'll have to learn more about how numerical values are stored and handled in Blender. Thanks for pitching in and getting me to think about these matters. I... think that maybe 119,617 pixels is more than I should have in a single row and will be looking into splitting that into multiple rows each with fewer pixels (which should give larger fractions less susceptible to rounding-off errors).

Thank you all for the very thoughtful replies. I have a better sense of what's causing the error and I figured I'd share for those in the future who experience this.
The problem has nothing to do with numerical errors. I learned a lot about numerical precision and some best practices to keep in mind, like using 32-bit EXR image textures for very large particle systems to avoid rounding-off errors, but I'm happy to say that my issue has to do with the particle index itself.
The real problem is probably that I went on the assumption that the index of a particle would match that of the underlying vertex (from which it is generated). But, it seems, at least for some particles, that is not the case.
I checked the actual location of a specific particle (#32263, the Hipparcos catalog number for Sirius A), and compared it to that of vertex 32263. Turns out the two are in different places on my screen.
I also checked which vertex the particle coordinates correspond to. It's vertex 32250, or minus 13 positions left of 32263—precisely the error I had observed for this star (which, mysteriously to me until now, had been getting its color from a pixel 13 positions left of where I expected it to be).
I haven't corrected the issue yet—now I have to figure out why the particle and vertex indices don't match (I guess they generally don't?) and see if I can constrain them to be the same—or, if I can't, at least figure out how to map the particle indices to the vertex indices (a must, since the vertex indices match the Hipparcos catalog indices, which I need to retrieve the star properties in my Python script).
Hope this helps someone in the future and thanks everyone again for patiently writing your responses. I learned things.


text:
View input vector values of Image Texture node?
I'm troubleshooting a model in which I have an Image Texture node with a generated image 119,617 pixels in width. As the node accepts the pixel coordinates in normalized form only (from 0 to 1), I have to divide the pixel indices (0,1,2...119616) by their total number (119,617).
I'm getting unexpected results, in which the colors of the image texture are offset by a certain number of pixels (in some cases upward, in other cases downward), which led me to suspect this was a numerical error, maybe a rounding error due to limited precision of the Math node.
In other words, maybe the number of decimal places kept in the division result (e.g., of 1/119617) was too small to precisely capture the pixel positions (and therefore to correctly locate them in the image texture).
As answered here, this does not seem to be the problem (though not knowing the cause just yet I can't be 100% sure).
To better troubleshoot this issue, I'd like to look at the vector input values of the Image Texture node. These are the normalized pixel positions. I know that the Data-Blocks field of the Outliner panel has a lot of data, but the Input section for the Image Texture node doesn't show the vector values themselves.
Knowing that things that can't be done interactively in Blender often can be done with Python code, I'm wondering: is there a way to access those input vector values with some Python commands?
Many thanks in advance if you know the answer and care to share!

To view the vector values, you can plug what goes to the texture node to Emission shader and render those vectors as colors.
You can check only values stored in input fields from python, the nodes are not processed when querying these values. Value outputs will just give 0.0. The shader node tree gets executed when rendering.


text:
Decimal places in RGBA values of Python-generated image?
I wrote a Python script to generate several image textures for use in Image Texture nodes. All the calculations yield values with many decimal places (some being on the order of 1e-7).
Printing the results of the calculations themselves to the console shows the values in full (or at least sufficient) precision. Printing the RGBA values of the generated image pixels for the image texture node, however, shows only one decimal place—with minuscule values being reduced to 0.0.
For this particular image texture node, this precision is not just a matter of display on the console. It really does seem that the RGBA values are 0.0. I say this because scaling the output of the Image Texture node by 1e7 has no effect (on color strength, which the node serves to control); yet, adding a 1e-7 to the output and then scaling suffices to get a nonzero color strength.
I figure that somewhere between the calculations themselves and the storing of the results in the generated image pixels, something is happening. This seems true: printing the RGBA values of the pixel entries in the generated image itself shows 0.0s instead of the small numbers I saw when printing the calculation results.
I'll post more detail if needed, but does anyone know why this might be happening? I should note that this kind of rounding doesn't seem to be happening for a different image texture file (whose values have many decimal places, though all are sizable fractions between 0 and 1, as opposed to being on the order of 1e-7).
Thanks in advance!

Related : https://blender.stackexchange.com/q/75066/29586. Note that by default a packed image will be packed as 8-bit. This will significantly affect precision. The solution is to ensure it's packed as 32-bit float but for this it seems it needs to be first saved to disk and then re-load it before packing.

See also https://blender.stackexchange.com/a/75429/29586 which generates in image from float values and stores as a 32-bit float image consisting of a single row of pixels.

Thanks!!! This is exactly what I needed. Saving in 32-bit EXR format resolved the issue with the image texture. The pixel RGBA values now have the decimal places that I expected and wasn't seeing before. Sadly... the numerical issue in my model persists, so now I have to search for its cause elsewhere. For some reason, the particles in my models are getting their colors from the wrong pixels—in some cases from pixels to the right, in others from pixels to the left. It seems like a numerical error and I can't figure out why it's there...

Glad to help. I did post a comment to your quesstion https://blender.stackexchange.com/questions/116110/ relating to offsetting each coordinate in your texture by 0.5 pixel - does that help with your other issue? You example is currently sampling the image right on the pixel boundary (add 0.5 to the Image index prior to the Division node and also use 0.5 in place of the 1.0 in the Combine XYZ node).

While I've learned a lot about using image textures to control particle properties (thanks!), my issue sadly persists. I've switched to 32-bit EXR images, which helped with precision, offset my image texture input coordinates by half a pixel to ensure that the sampling is within a pixel, and even split my image texture into a 347 x 345 matrix to avoid dividing by a very large number (as I now have to divide by 347 at the most, instead of by 119617). Still checking the results from the last step, but as of now, my particle colors are still being sampled 9-13 px away from their correct places...

Images are usually created and packed as PNGs as 8-bit sRGB format. This severely limits the precision of the RGBA values stored. To improve precision you need to force the image to be stored in a format that supports 32-bit float channels such as EXR format.
To use a simple example, storing as an 8-bit image would be limited to steps of 1/256 or approximately 0.0039 - any value below around 0.002 would be rounded down to zero and any value from 0.002 to around 0.006 would be rounded to 0.004 (or 00000001 in binary). The actual values used for each 'step' is further complicated by the sRGB color conversion (which stretches the color space in order to produce a more practical range of colors for display on a screen - see Wikipedia sRGB
Examples of storing images in 32-bit float EXR format can be found in Creating and packing a 32-bit float image and Capture object properties to use in a Cycles material


text:
Bones don't respond to rigid body
I made a character with ragdoll physics, in which I made boxes with active rigid bodies, and parented them to the bones. Most bones react well, except for the right leg, which pulls away from the body when I play the animation.

How do I make sure it won't fly off?
I'm using this tutorial https://youtu.be/GaZAI8RIq0Q
.blend file:

Found your problem, there's a magic 90 degrees on one of your empty objects, if you reset to 0 it works like you wanted.

You can see the other empty that connects the other leg, doesn't have that 90 degrees on the X Axis.
Cheers,


text:
Generated image pixels not shown in UV/Image Editor
I used Python to generate an image texture which consists of a single row of colored pixels. The pixels each encode the color of a star, of which there are 119,617 (modeled as a particle system).
Trouble is, when I open the generated image in the UV/Image Editor panel, the pixels colors don't show.
I can see their alpha values if I switch to Alpha-only view mode, and I can click on the pixels to get their RGBA values (which are correct, and which are accompanied by a square showing the color itself).
Is there anything that might cause this issue? A setting that I can change to correct it?
Thank you in advance for any insight you can give!

Perhaps share your python code (or a cut down version that still triggers the problem) so that others have a chance of replicating it and tracking down thr problem.

Perhaps this is as simple as being that the unusual extreme dimensions of the image (119617 x 1 pixels) are beyond what the Image Editor is capable of handling.

That seems possible. I changed the image texture to be 347-by-345 pixels, and it shows up fine like that in the UV/Image Editor. Although, to be fair, I also changed the settings of the image itself, including its format (now EXR) and its bit depth (from the default 8 bit to 32 bit). I'll check again if the 119,617-by-1 image might show up now and update this post if it does. It's good to know if it there is a chance that it is a software limitation.


text:
Get number of particles with Python
I'm troubleshooting a large particle system and for that I'd like to get the total number of particles. Is there a Python command that I can use to retrieve it?
I expect this number to be the same as the number of vertices used to generate the particle system (and to be no larger than the number of particles specified in the Particles Properties tab), but I need to confirm to rule out one possible source of error in the model.
Many thanks in advance if you know the answer and care to share it!

In case you mean the number of live particles, rather than the total number of particles, you can get it thus:
o  = bpy.context.object        # Active object
ps = o.particle_systems.active # Active particle system
nLiveParticles = len([
    p for p in ps.particles if p.alive_state == 'ALIVE'
])

For the general number of particles, you can simply print:
print( len( ps.particles ) )

This will likely be identical to the number you've specified in your particle system settings, which you can also access here:
print( ps.settings.count )

So if your object is a mesh, and you want to test whether the total particle count or live particle count equals the number of vertices, you can just assert these conditions, and get an assertion error if any of them is false:
>>> assert len( ps.particles ) == ps.settings.count, "Total number of particles equals PS settings"

>>> assert len([ p for p in ps.particles if p.alive_state == 'ALIVE' ]) == len( o.data.vertices ), "Number of live particles equals number of vertices"
Traceback (most recent call last):
  File "<blender_console>", line 1, in <module>
AssertionError: Number of live particles equals number of vertices


text:
Setting particle color with generated m x n image texture
I have a large particle system in which the particles (stars) are colored according to a generated image texture.
The image texture was originally 119,617 wide and 1 px high. No matter what I did, the particle colors were sampled 9-13 pixels away from the correct pixel coordinates, and the random nature of the offset made me suspect a numerical error somewhere.
I've gone to lengths to verify that 1) the pixel colors are correct for the pixel coordinates, and 2) that the image texture has enough precision to correctly store this information (by saving the image in 32-bit EXR format and loading it to the appropriate Image Texture node).
This to say that I trust the image. This places the most likely source of the error somewhere between the Particle Info node, from which I obtain the particle indices, and the Image Texture node, where I assign the particle indices their colors.
The original mapping of particle index to pixel coordinate was straightforward. The image texture was a single row of 119,617 pixels, one for each particle, so the normalized x-coordinate (in the 0-1 range expected by the Image Texture node) was simply the particle index divided by the total number of particles (minus 1, because the count starts at 0).
I have concerns about dividing over such a large number, and to remove that division as a possible source of error, I've decided to make my image texture 347 pixels wide and 345 pixels high (approximately square). This would reduce any numerical error due to division by ~1e5. The last row of pixels includes some blank pixels, but I don't expect these to give me trouble, since they will correspond to particle indices that don't exist and will simply not be assigned.
Roughly:
The x-coordinate of the pixel to sample is calculated as the modulo of the particle index and the width of a pixel row (347 pixels). The modulo gives me the remainder of 119,617 / 347, which corresponds to the x-coordinate of the pixel. To normalize that coordinate to the range of 0-1, its value is divided by the width of a row (minus 1 because the count starts at 0).
The figure shows the node logic for the pixel row (y-coordinate) calculation (isolated for clarity).

The y-coordinate of the pixel to sample is calculated as the difference between the particle index and the modulo calculated above, divided by the width of a pixel row to get the number of the pixel row, divided by the total number of rows (minus 1, because count starts at 0) to normalize between 0 and 1.
(I added 1 to the particle index to ensure that the 347 pixel (and every nth multiple of it) falls on a new row; at worst, this adds a small systematic error that should be easy to catch.)
The figure shows the node logic for the pixel column (x-coordinate) calculation (also isolated for clarity).

I've verified that the pixel row makes sense (with a small error that I have yet to trace). Changing the pixel row (by adding one row or subtracting one from the calculation) gives me the expected color. I can't verify this for the pixel column (x-coordinate), as the color doesn't seem to change...
The figure shows the image texture I used for testing. The different color ranges are there just to give me a sense of which pixel in the image texture a chosen particle landed on (that particle being #32263, the Hipparcos catalog number for the star Sirius A). The magenta pixel between the yellow and blue pixels is the correct color for that star (row 92, column 339 of the image texture).

Below is the disappointing result. Sirius shows up yellow. I spent an inordinate amount of time (on the order of days) just adding and subtracting from the calculated pixel coordinates, trying to get the magenta color. Shifting the pixel row up by 1/344 turns Sirius A blue. Shifting the pixel row down by the same amount turns it red.
Sadly, doing this to the pixel column seems to have no effect. When the image texture was a single horizontal row, I was consistently off (for this particular star) by -13 pixels.

Has anyone struggled with controlling particle properties with image textures larger than 1 pixel in height? Can you suggest a better way to calculate the x- and y-coordinates of the pixels to sample? Can you see anything that could cause this error (because sadly, I can't)? I would love to move on from star colors (so much more to do) but it's critical that the colors be precise...
Many thanks in advance!
EDIT: Manually entering pixel coordinates in a Combine XYZ node and feeding them to the Image Texture node gives me the correct color (which, of course, being just a single number with no reference to particle index, is applied equally to every particle). The fractions in the Combine node are 339/346 for x, 92/344 for y, and 0.5 for z.

...Yet, calculating those exact same numbers from the particle indices gives an error. I've been grappling with this issue for a week and can't see what could be wrong. Could it be that the Index output of the Particle Info node is off somehow?
EDIT: I've verified that the mapping from particle index to pixel coordinates is correct. I did this by replacing the Particle Info node with a Value input node and setting the value to 32,263 (the particle I've been using for testing). This gives me the correct color. Adding an offset to the mapped pixel coordinates changes the color as expected, and going outside of the width and height of the image texture makes the particle go black (because no color).

However, adding back the Particle Info node (and making no other changes) brings back the incorrect color mapping.

This means that the issue is in the index output of this node. I can think of two possible issues: the node itself outputs the wrong particle index (although I consider this sort of bug unlikely); or the particle index does not correspond to the vertex index, which is what I've been using for testing.
This leaves me wondering: could the particle indices be different from the vertex indices from which they are generated? Is there anyway to ensure that they are the same? I realize that this post has grown out of proportion, so at this point I am mostly documenting my struggle with this issue and my search for an answer or workaround...
EDIT: Having run more experiments, it is now clear that the issue is not a numerical error but a mismatch between the indices of the particles and those of the vertices from which they were generated.
In my testing, I have been going on the assumption that each particle would be placed at the coordinates of the vertex of the same index. I saw no reason why this shouldn't be. I didn't use any randomness in my model, and there were no child particles. So it seemed that vertex 32263, for example, would spawn the particle of index 32263.
But this is not so. The indices weren't off by much: only -13 places for particle 32263 (out of 119617 total). But they were off, so no matter what I did to the image texture or to the calculations used to map particle indices to image texture pixels, the colors were never correct.
I checked that the issue was in fact the index mismatch by accessing the location of a test particle (32263) and comparing it to the location of the vertex of the same index:
import bpy

obj = bpy.data.objects["starPoints"]
ps = obj.particle_systems["ParticleSystem"]
p = ps.particles
v = obj.data.vertices

print("p32263 Original:", p[32263].location, "p118442 Original", p[118442].location, "p27919 Original:", p[27919].location)

print("v32263 Original:", v[32263].co, "v118442 Original", v[118442].co, "v27919 Original:", v[27919].co)

n = len(p)
for i in range(n):
    p[i].location = v[i].co

print("p32263 New:", p[32263].location, "p118442 New", p[118442].location, "p27919 New:", p[27919].location)

So now my task is to make the particles each coincident with the vertex of the same index. My issue with particle color should then go away entirely. Will respond with an answer if it works and accept it to close this thread since it hasn't attracted any answers. Hopefully this long post will come in handy to someone down the line (probably in 5-10 years time, if Cycles is still around :D)


text:
Rotation speed setting?
Just wondering if there is any add on, feature, tool or third party software to set an object too rotate at a certain speed during animations such as making a wheel rotate at 1000 rpm or something like a drill drilling at 150 rpm. Any answer is appreciated. Thanks.

For this you need to do a little math. We need to find out how much the wheel spins withing 1 second.
Let's say you render at 30fps and one rotation equals 360°. First we have convert rotations per minute into rotations per second. Then we have to convert rotations per second into degrees per second.
1000rpm / 60s = 16.667rps

We multiply 360° by 16.667rps to get how many degrees it spins in a second.
16.667rps * 360° = 6000°ps

The wheel spins ~6000° per second. To find out how many degrees it spins in a frame, divide the spins per second (6000°) by the number of frames per second (30fps).
6000° / 30 = 500°

The wheel needs to spin 500° per frame to complete 1000rpm.
To do that, go to frame 1 and set a keyframe at 0° rotation. Then set a keyframe at 500° rotation on frame 2. To make it continue speaking, location the rotation fcurve in the graph editor, select it and press ⇧ ShiftE > Linear Extrapolation. (See this related answer.)
You can also use this online calculator.

Thank you, I haven't thought of that, will try to use that more in the future

For constant rpm use a driver
Similarly to answer by @DrachenSeele some simple maths.
The frame rate of your blender scene.  Test in python console, where C = bpy.context
>>> fps = C.scene.render.fps / C.scene.render.fps_base

Convert revs per minute to revs per frame
>>> rpm = 150
>>> rps = 150 / 60
>>> rpf = rps / fps

Make this an angular velocity.  Note that blender uses radians as its native unit of angle. (displayed as degrees if that is the unit set in scene units)  One revolution is 2pi radians.
>>> angular_velocity = 2 * pi * rpf
>>> angular_velocity
0.6551529985521121

Ok now add a simple driver 0.6552 * frame (rounded for example sake) to a rotation value, an axis of euler rotation or an angle of angle-axis rotation.
The expression above can be typed directly into the field with a hash prefix to designate it as a driver  #0.6552 * frame The variable frame is known to the driver namespace and is the value of context.scene.frame_current.

Driver added to default cube to spin around X axis at 150 rpm.  Notice the sampling rate of animated gif makes this look sluggish due to the wagon wheel effect
To avoid the wagon wheel effect try setting the rpm to a prime number  near the target rpm (eg 151 instead of 150) or add a slight randomness to the driver.
0.655153 * frame + noise.random()

mathutils.noise module is known to driver namespaces as noise
Also note that this is easily extended using the driver system.  Another driver variable could be a custom property ranging from 0 to 1, eg stopped to full speed which can also be animated.
An example using an rpm custom property.
similarly to above make a custom property named "rpm"

Make a driver

check the use self option, this way self["rpm"] is our custom property.  Can get the fps from the scene. I haven't bothered with base frame rate per example here.  Also notice this spits the "slow driver expression" warning. I don't think for simple examples like this it is an issue. I have enquired here Use self and the slow python expression .
The expression
pi * frame * self["rpm"]  / (30 * fps)

Now I can adjust the custom property to spin the cube around Y (where i stuck the driver) at the designated rpm.

If you want it to increase your rotation speed try changing the frame rate to a faster setting and adjust your animation to suit it.

This would not be a good solution as other things need to be at a certain speed too

You can use rigid body
You just need to use "hinge" and "motor",
With that, you can set the " Angular Velocity"
You can also control the "Torgue"

This question is asking for angular control at a high rate, not how to simulate rotation


text:
Changes to particle problems not showing in 3-D View panel
I'm using Python to change the positions and sizes of particles in a particle system. The Python code seems to work: when I print the new positions and sizes of particles, they are as expected. However, none of these changes will show in the 3-D view panel.
This is not a simple issue with the visualization not updating automatically upon running the script (which some people have asked about). Even when I take steps to update the visualization (for example, changing from render view to material view and back), none of my changes are evident.
Is there a reason for this—and better yet, is there a way to make sure the changes I make with Python reflect in the model?
Thanks in advance!

Change the current frame.

You mean the current animation frame? Any reason why that would work? Just trying to understand the rationale for the suggestion. Thanks!

Only because thats the time it reads the existing location to calculate its new location. Guessing that viewport refreshing doesn't refresh cached particle data, but changing frame means it needs to get the new position.

Aha! Thanks! I just learned something worthwhile. Looking forward to giving it a try tomorrow. I've been battling with this model for weeks, and if this works, man, I'll... open a metaphorical bottle of champagne, because I don't keep real bottles around, but the excitement will be real :D

Bummer. My hopes were up but sadly changing the animation frame has no effect. So strange that my changes reflect in Python but not in the visualization of the model. The new particle positions printed in Python are correct as are the new sizes, yet this is the extent of these changes, apparently. Wondering what else could leave the visualization so stale.

Could you provide a minimal example that shows your problem and upload the script and .blend? Then maybe we can help, but I haven't encountered your problem and have no spontaneous solution


text:
Highlight logic of vertex selection
When I select a vertex in Edit mode, some—but not all—of the edges that terminate at the vertex are highlighted. Moreover, which of the edges are highlighted can vary across a surface.
The image below shows an example. The selected vertices are on the periphery of a hole. Some of the edges highlighted radiate outward from the hole along the outer surface of the part; others point inward along the cylindrical surface of the hole; still others connect adjacent vertices on the periphery of the hole.

Just wondering: why are only some edges highlighted? Why is a particular edge highlighted and another not? Just trying to understand so that I can better interpret what I see in Edit mode. Thanks!

Highlight goes to above a half of the edge between selected and connected vertex. If it isn't visible then there's another geometry present there (vertices cutting those edges), like for example on your screenshot there are multiple double vertices, probably loose edges etc.

Thanks for the response. However, there are no duplicate vertices or loose edges. Also, each vertex connects to more than one vertex, yet only one of the connecting edges is highlighted. This can't be due to some edges being occluded, as I rotated the view in several ways to see if it had an effect... and it didn't... Just trying to understand what is actually going on. Thanks!

Just to be sure, when you move  a highlighted vertex, do any non-highlighted edges move with it?

They do not... and I see now that my mesh isn't that clean after all. Blender didn't find any duplicate vertices when I selected the option to remove them, but clearly that is no guarantee that the mesh is free of what are... at least almost... duplicates. Moving the selected vertices exposes what is an almost identical surface directly underneath (meaning coincident with that to which the vertices belong). I created the mesh in CAD, and the software probably doesn't optimize for clean meshes. I'll take the sort of highlighting I described in my post as a sign of a dirty mesh in the future...


text:
Boolean Modifier Dissapearing
When I apply a Boolean modifier to say a cube during an animation and link a cylinder as the Boolean object and animate the cylinder going through it, when the cylinder goes all the way through the Boolean modifier disappears on the cube and it becomes solid again, is it possible to make the cube contain the hole through it after the cylinder has passed through it. I have tried the carve feature instead and it still doesn't work. Any help is appreciated, thanks.

For animaton you need to create keyframes, that are inserting by pressing I. Creating or removing smf are not a operation that can be keyframed.
Instead of this try to animate displaying of modifier. So do the following:

Go to the 1 frame
Hover cursor on eye icon  and/or camera icon and press I
Go to a frame that you want to hide modifier
Disable modifier (eye icon disables in viewport, camera - in render)
Hover cursor on eye icon  and/or camera icon and press I

It will create an animation, that will hide modifier after chosen frame
For creating a hole, I recommend to create a copy of cylinder, that will not leave a cube, and make them invisible for render:

You can do it in outliner.

That's know really what i  wanted to know but good information for the future, I want to know how to make it so that the modifier doesn't automatically disappear after the cylinder has passed all the way through. I have a cylinder animated so its traveling through the cube and it disappears after it gets through and the cubes "fills itself" right after I want to know how to make it so it doesn't disappear and the cube maintains the hole.

Create a copy of cylinder, remove animation for this and hide it from render. So, one cylinder will be for hole, one for animation.


text:
Select vertices, which are affected by a shape key
Is it possible -- without using a previously defined vertex group -- to select those vertice, which are affected by a shape key?
How?

perhaps to make the question clearer, do you mean is it possible to know exactly what vertices are affected by a shape key? I haven't heard of that

I think a shape key stores the coordinates of any vertex of the mesh, regardless of whether the position has been changed or not. So it seems as if the only way to select vertices affected by the shape key is to individually compare whether the position of the vertices is the same for different shape keys.
import bpy
tolerance = 1e-5
obj = bpy.context.active_object
shape_keys = obj.data.shape_keys.key_blocks
sk1_data = shape_keys['Key 1'].data
skb_data = shape_keys['Basis'].data

bpy.ops.object.mode_set(mode="EDIT")
bpy.ops.mesh.select_all(action="DESELECT")
bpy.ops.mesh.select_mode(type="VERT")
bpy.ops.object.mode_set(mode="OBJECT")

for i, (x, y) in enumerate(zip(sk1_data, skb_data)):
    if (x.co - y.co).length > tolerance:
        obj.data.vertices[i].select = True

bpy.ops.object.mode_set(mode="EDIT")

EDIT: As per batFINGER's suggestion, replaced comparison based on equality with a tolerance based approach.

BMesh version
Using the same principle as @binweg's answer with an edit bmesh

Shapekey vertex coordinate needs to be further than TOL (local) from vertex coordinate.
Always suggest using a tolerance approach when looking at floats,
rather than relying on 10.0000000001 == 10 for example.
The two points of interest are vector coords.  Test the length of the vector
calcuated from their difference.
Uses the active shapekey.
Selected result is those verts further than tolerance from base mesh,
IF the shapekey is the solo shape at full value
For the script to "poll" needs to be run in edit mesh mode. The
object must have an active shapekey.

script
import bpy
import bmesh

context = bpy.context
TOL = 1e-5 # tolerance
ob = context.edit_object
me = ob.data
bm = bmesh.from_edit_mesh(me)
ask = ob.active_shape_key

for v in bm.verts:
    bv = me.vertices[v.index]
    v.select = (ask.data[v.index].co - bv.co).length > TOL

bmesh.update_edit_mesh(me)

I might have used this script wrong, but for me this script doesn't work. In edit mode bm's values always seem to be identical to the active shape key's values, so for me there is no selection. Only by replacing v.co with me.vertices[v.index].co or ask.relative_key.data[v.index].co I manage to run it. I appreciate your suggestion of using tolerances. I initially decided against it as I was under the assumption that, even if some coordinates are not exactly integers, when you create a new shape key the value gets copied just like it is. But I guess it's better to be safe than sorry.

@binweg cheers... Have used the mesh coord as suggested.  Forgot the nuances of different bmesh modes.  from_edit_mesh vs from_mesh vs from_object.   A second non live edit bmesh could be another way to go, but ultimately the mesh vert coord is the go.


text:
How do you rig a character that has multiple individual meshes?
I have a creature with multiple hand placed scales all over it's back side which are all separate meshes. How do you rig them to the character itself without causing clipping?
Do I have to manually weight paint every single one of them? They are about 200 of them. Or do I add individual bones to each scale?
Does anyone know an effective way of rigging something like this?

is each scale supposed to move independently? what did the Parent > With Automatic Weight give? Perhaps make a screenshot so that we can understand better your topology and armature...

For curiosity sake, can you add a pic of said creature?


text:
What's happening with vector displacement 2.79b?
pretty quick question. I use the vector displacement node in order to add greebling to models. The latest version of 2.79b doesn't have that node, which seems to be why sheepit render farm is returning "flat" non displaced models.
Does anyone know if I should just wait for an update? Or if there is a way to do displacement without the vector displacement node?
Thanks guys, appreciate any advice!

You need to download the daily build to get that feature, it is an experimental feature.

@Denis Well not so much an experimental feature, it is a new feature that was added after the 2.79 release and hasn't been included in an official release yet. It is in 2.80 alpha2 but I don't think that helps with using sheep it.

Try connect it directly. For example, connect Image Texture color output to Displacement input of Material Output node.


text:
Bones move out of mesh when changing from Edit mode to Object mode
I imported a mesh to play around with it and I tried to animate it so it put bones in it. When I am in editor mode everything looks right but when I change the mode the bones of the torso are moving out of the mesh:
I was able to find something in the Internet but it didn't work.
Thank you!

could you please share your file? https://blend-exchange.giantcowfilms.com/

Yeah, sure:

You have a bit messed up your armature in Pose mode, so you need to switch back to Pose mode, select all your bones, then alt s, alt r, alt g (reset scale, rotation and location)

Thank you!! How can I avoid this in the future?

if you don't go in Pose mode, it won't happen. Once you go in Pose mode, you can move your bones as much as you want, record the new poses with keyframes, go back to the initial pose with alt r s g, etc... you should learn all this with animation tutorials


text:
Cycles weird baking behavior: changes to another image texture mid-bake
Blender enthusiasts!
I'm nearly done with Aidy Burrows' Game Asset Creation course and ran into weird baking behavior from Cycles while making my final textures for the game model.
Details of the mesh: all separate parts recently joined into one mesh; has one main UV map and two additional UV maps for two more detailed parts of the mesh; has a simple Cycles material that only uses a handful of image textures: baked and hand-painted textures combined with a normal map.
I have prepared an image for the final diffuse texture and another for final normal map to be used with the model in the game engine. Problems arise when I'm trying to do these final bakes. During baking normals Cycles decides to switch to the already existing AO image (named AmbientOcclusion in the screenshot below) and then bake the AO (not normals as I have requested) again on the final normal map that I have specified as the bake target image. Still following? This image might clarify things:

And yes I do have two image nodes in my Node Editor ready for the corresponding final texture (diffuse map) and normal map.

Can anyone help clarify if I am doing something awfully wrong or if Cycles is making me go crazy? I see no logic in it's behavior when I select 'Normal' in Bake Type, click Bake and end up with AO on top of my normal image canvas. I have restarted Blender and my computer to see if it was just a reference issue or something but alas, no luck.
EDIT: In fact, when I try to do the diffuse bake (with only color selected in bake settings) Cycles manages to bake on the right image even though the information displayed in the info bar is still wrong:

...because I'm baking diffuse on to a image named ConeHat_d.
What's going on?

Try to select the Image texture you want to bake to in the shader editor.
In my case it helped.
Cheers,
Robert

Alright, after some hours of needless research I figured it out on my own.
My model was using 3 separate materials: one for main mesh, one for camera details (painted and baked textures) and one for cable ribbon details (also painted and baked textures). I had placed two image nodes - one for final diffuse texture and one for final normal map - only in the main material. I had to copy the two nodes also to the remaining two materials I used for detailing. Now baking worked as it should.
I imagine previously when I hadn't specified the bake targets for the remaining two materials Cycles was just picking a random texture node already present in the node tree and baking on top of that - and in this case it was my ambient occlusion map which was shared among all the three materials.
Hope this helps others struggling with trying to bake multiple materials into one final texture.


text:
Character eyes are black
I made a pair of eyes for a character of mine that consists of two meshes. One that acts as the real eye with the iris and the pupil, and then a copy of that one but slightly different to represent a cornea which has only a simple glass shader on. Why are the eyes of my character dark as soon as I place them inside the eye sockets? Seriously, you can barely see them. Can anyone tell me why Blender does this?
Eye out of socket:

Eye inside socket:

From a distance you can't see it's eyes at all, only if you're this close can you make them out.
Blend file: https://www.dropbox.com/s/vj7jwmcu7sn7bej/Dark%20Eyes.blend?dl=0

Try to increase the Transmission and Glossy bounces.

It became a bit clearer but it's still too dark. I wanted them to be vibrant, almost like sapphires.

Can you attach the .blend please

I added a dropbox link to the blend file on the post.

You probably need to pack the textures into the .blend, can't see them. EDIT: whoops, sorry, it seems only the World-HDR image was missing.

For me it looks like only a lighting-issue. More light to the eye-side should be enough.

It is hard to see it all without all the pictures packed (or I just don't have HDR activated), or that the head is lacking materials. However, I myself have had a few troubles in regards to things being not lit the way I like it. One of the things involves having specularity spots on eyes even in a dimly lit room. The two options I came up with was having "virtual lights" (spot and point) surrounding the face, and having a starfield texture added as emission.
I have played around a bit with your node setup, and what I've come up with is that from the Mix node that is connected to the Principled's Base Color, add a connection to a Bright/Contrast node, connect that to an Ambient Occlusion shader, and then an Add shader that adds together the Principled and Ambient outputs to the Material Output.
With the Bright/Contrast node you can control how bright/vibrant you want your eye, seeing as AO (and Add) doesn't have a slider for how much it affects the material. If you want a "strength slider" for the shader, or don't mind the eye emitting some light, you can exchange the AO shader for an Emission shader.
Hope this helps.

This did help and now I can see the eye clearly but it looks flat.

At least it is a start. Play around with what I've given you, exchange or add some nodes, or connect them differently. Hopefully you'll achieve the result you are looking for.


text:
Blender very laggy
So I have an MSI GeForce Gtx 1080Ti 11Gb and an Intel i7 7820X but when I open up a scene in blender and try to pan around in solid mode and when I try to preview the animation it only plays at 1 fps I am wondering what the "Mem:" stat is on the top of the interface because my computer should not be struggling to perform simple tasks, I have tried increasing my memory cache amount and that doesn't seem to help,  I added a picture to show and I have tried reducing geometry and all that in the scene but when I try to bend my objects like they are supposed to instead of bending in a curve they bend as the two end points follow the path and it doesn't curve at all so reducing geometry isn't really an option, any help is appreciated. Thanks.
Edit: I checked my GPU and CPU usage and they sit at 5% and 10% respectively which confuses me because blender is so laggy even after a fresh install.

Well, you have 2.5 million vertices, and blender viewport is currently known to poorly manage all that geometry. 2.8 will raise opengl release used, and this should improve much, hopefully.

This is because your scene looks complex. It has 2.5 million vertices 2 million faces and 5 million tris. The blender viewport cannot maanage all that geometry all together . Maybe 2.8 is. Realeasing fixes to thus you can try that..

Incorrect. There is not enough information to dismiss this as Blender being not capable. 2.79 handles same amount of geometry with high resolution textures with only some lag on a machine with a lot lower specs - i7 6700, and GTX970. In edit mode it lags more if material shading is enabled or the mesh edited is very high resolution. The problem might be graphics drivers being not up to date. Obviously if a 4k monitor is connected it might influence performance.

Well I know that I have a lot of geometry but it is required for the animation as each piece is imported from SolidWorks and re-meshed so that they have the same quality, but if I don't re-mesh them they won't bend around a curve properly so I have to add lots of geometry, I guess what I was asking is if its a problem with blender or if there is something I can do to fix it because my computer is very capable of handling that and I was also asking what the "mem" stat is because if it is internal memory or ram my 11gb graphics card should be able to handle it as well as my 32 Gb of ram.


text:
Textures will not appear
I'm trying to add textures to an object through the materials/textures panels, but no matter what I do, it won't work.
Render viewport mode just gives me black. Texture and material viewport modes give the color of the material but not the texture. Cycles render, blender game, blender render, all useless.
Maximum Draw Type is already set to "textured" and nodes don't work. I've been searching for an answer for hours and nothing's worked.
EDIT: There is no option to add an "image texture" anywhere in the materials tab. Not that it matters, because even the pre-loaded textures don't appear.
Here is the file:

EDIT EDIT: I also do not get an option to "unwrap" and even before that, I get nothing but a black texture.

EDIT EDIT EDIT: I get the brick texture on the body but not the hair. Using an image also gets just plain gray, not the image as a texture. And when I switch to Blender Render it turns bright orange.

hard to tell, please share your file: https://blend-exchange.giantcowfilms.com/

Uploaded

You have to switch to material shading to view procedural textures and to textured shading to view the actively selected texture node. The answer of the duplicate question can be reproduced with your file. Image (click me)

No it can't. I just get a blank black texture


text:
Constrain vertex positions to moving objects?
I have a schematic of a mechanism on which I would like to superpose an animated 2-D line drawing (a simplified representation of the mechanism).
I'm struggling with a few things, including how to draw the 2-D lines without faces. For now, I've decided to draw a single polygon (which I can render as a wireframe with Freestyle or with the Wireframe modifier).
But to make this work, I need the vertices of the polygon to move with the joints of the underlying mechanism. The edges between the vertices would correspond to the parts connected through joints, and they would rotate and translate as the vertices move around.
All I know at this point is that I can move the (here polygonal) mesh origin to a vertex and constrain the mesh position to another object. But this leaves me with all the other vertices that I'd like to constrain in a similar manner. If I simply move the mesh origin to another vertex to constrain that to another object, the first constraint changes and I'm back to step 1.
Thanks in advance for whatever help you can give!

You can constrain each individual vertices of your polygon to the joints of your mechanism instead of moving the mesh origin. No need to move the mesh origin.
You can do it using the Hook modifier. Create one Vertex group for each vertices of your polygon, then, using the Hook modifier, constrain each of those group to one of the joint of your mechanism, using whatever mesh that makes up the joint that you think would show the best result.
Alternatively, you can use some Empty, constrain them to the center of the joints, then Hook each Vertex group to one of the Empty.


text:
Smooth Freestyle Lines
I'm struggling to get crisp and smooth lines with Freestyle (in Cycles). I can clearly see jagged edges, the sort you'd expect from the lack of antialiasing. Is there a way to apply antialiasing to Freestyle renders? Can I do anything else to get presentable images that I can use? I love what I can do with Freestyle, but I have yet to get results that I'd feel OK with publishing. Example below. Thanks!

Do you have any kind of dashed lines enabled? Could we see your line settings?

Increase resolution and increase line width. Anti-Aliasing is basically rendering at increased resolution and downsample later

Thank you for the comments. I do not have dashed lines enabled. I'm happy to upload a screenshot of my line settings, but there are many tabs for the line styles (Thickness, Alpha, Color, Geometry, and Texture, I believe), not to mention different areas in which to change Freestyle settings. Just wondering which settings in particular would be relevant here?

I did experiment with many different settings, including the resolution and line thickness. Increasing the resolution seemed to make things worse, in part because the image becomes larger and so I have to scale it down for publishing. I avoid scaling raster images, because inevitably my graphics become fuzzy, though here, the issue is that my lines become scraggly. I did try increasing line thickness along with the image resolution, and while the lines turned out less scraggly, they were far too thick for the eye. I've seen perfect Freestyle lines that are very thin, so I know it can be done..

@Alex Hm, probably the easiest way would be if you could upload a .blend (e.g. with just a cube) for us to examine.

You've probably solved the problem by now but I just ran into this problem and found an easy solution: increase the Render Samples to 30.
I had the same problem when Cycles only computed 1 sample. At 2 samples, it was much better and so on.
I hope that helps someone.


text:
What's the fastest / least destructive and most scalable way to create a step pyramid?
I want to create a step pyramid. Not a smooth three dimensional triangle with five faces, but a pyramid with "steps", like this:

Requirements:

Creating the pyramid should be fast!
You should be able to control how many "steps" there are
No matter how big, the pyramid needs to be consistent, meaning all the steps have the same height and the distance between the inner corner to the outer corner of a step is the same

The "actual" pyramids you are likely referring to did not look like this. What we see today is the skeleton.

@pipe Actually some of the earlier pyramids were step pyramids. Certain nations only knew how to do step pyramids to begin with, and didn't figure out how to slope them until later. E.g. The Pyramid of Djoser

@noClue Technically the "smooth 3-dimensional triangle" is the 'proper' pyramid. What you're asking for is a kind of step pyramid.

Guys... I think everyone will know what I actually meant.

Actually, no, I didn’t—reading only the title, I absolutely thought you meant the mathematical figure properly referred to as “pyramid.” The current phrasing is misleading and unhelpful, and should be changed. I have suggested an edit along these lines.

There is a builtin addon for that, no need to reinvent the wheel.
Under the User Preferences > Addons make sure Add Mesh : Extra Objects is active.
Then in the 3D View simply press Shift + A > Mesh > Extras > Step Pyramid
You can then adjust the builtin parameters as desired.

Only downside is that the addon seems to generate pyramids radially, hence a four sided pyramid seems by default rotated 45° about the Z axis in relation to world coordinates, it also is kind of destructive, in the sense that it can't easily be changed or its parameters adjusted after creation.
As mentioned by @batFINGER the Reduce Step By value needs to be twice the value of the Height parameter to obtain "square steps", where the riser matches the tread depth. Andrew Morton then clarified this is due to the reduction value being applied in relation to total base diameter, taking into account steps on both sides, rather than an absolute tread depth, thus apparently halved.

Crunching in 45 in for rotation z on creation is one way to "fast" fix.  Could you elaborate on how to set reduce step size, eg how and why it needs to be 2x height for consistent step size?  Suppose I've  gone down the wheel  re-invention path somewhat with answer.  As mentioned for an irregular base bending the regular primitive whilst keeping insets consistent could prove difficult for some.

Nice addon! Activating.

@batfinger I'll have to check on that later, not at the computer right now, never actually used this before this answer. Keeping insets consistent is a frequent problem I encounter too often when dealing with bezier curves bevel objects also. When the "curvature radius" is shorter than the section dimensions it leads to self intersections that are hard to deal with.

@batFINGER It's twice the height because there are ledges on both opposite sides.

@batFINGER I caved in to your pressure, details added

The simplest solution is probably the Remesh modifier:

Create a simple pyramid out of five faces. You can do that by selecting the four vertices of the top face and merging them (Alt+M then select At Center).
Add a Remesh modifier. Set Mode to Blocks.
Increase Octree Depth until sufficient number of pyramid steps has been achieved or surpassed.
Decrease Scale to reduce the number of steps.
Apply the modifier, optionally tweak the object scale.

At this point, you already have a pyramid shape but its mesh is rather dense. To clean up the mesh:

Switch to Edit Mode (Tab).
Press Space and search for Limited Dissolve. This fixes vertical faces but it leaves horizontal faces with the wrong edges.
G to Mesh > Clean Up > Split Concave Faces. This splits the horizontal surfaces in the way we want. Be sure to select all of the faces.
Press Numpad 7 , Numpad 5 then 3 x Numpad 4 to switch to top-down view rotated 45 degrees.
Box select the north and south slopes and press Space and search for Limited Dissolve again to remove unwanted edges.
Repeat once again for the west and south slopes.

Now you can efficiently tweak the mesh. To remove the bottom step, select the bottom face, then press Ctrl + Num > X > Dissolve Vertices. Similarly for the top step.

A bmesh solution
As an exercise wrote a bmesh script to take a single ngon mesh and make it a consistent pyramid with steps steps of size step_size.
I've used the the primitive plane add as a default ngon. Comment that part out, manually add any single ngon face object, select it,  and run script in object mode.
Basically the script takes a face, makes the base (solidify),  then insets and extrudes along the normal for each extra step of the pyramid.  By no means the quickest way to do this, however for non-regular based pyramids produces solution which may be easier than editing from regular pyramid created using extra objects addon's stepped pyramid.

Sample runs, on default plane, filled ngon circle, and arbitrary 6 sided ngon shaped mesh
import bpy
from mathutils import Vector
import bmesh

step_size = 0.1
steps = 10
# remove and make some single ngon active mesh object for arbitrary base
bpy.ops.mesh.primitive_plane_add()
context = bpy.context
ob = context.object
me = ob.data
bm = bmesh.new()
bm.from_mesh(me)
faces = bm.faces[:]
vec = step_size * faces[0].normal #* Vector((0, 0, 1))

# make the base
bmesh.ops.solidify(bm, geom=faces, thickness=step_size)
bmesh.ops.translate(bm, vec=vec, verts=bm.verts)
steps -= 1

for s in range(steps):
    bmesh.ops.inset_individual(bm, faces=faces, use_even_offset=True, thickness=step_size)
    ret = bmesh.ops.extrude_face_region(bm, geom=faces)
    faces = [f for f in ret['geom'] if isinstance(f, bmesh.types.BMFace)]
    verts=[v for v in ret['geom'] if isinstance(v, bmesh.types.BMVert)]
    bmesh.ops.translate(bm, vec=vec, verts=verts)

bm.to_mesh(me)

You can do this by using an Array modifier and an Empty.

Create a new cube, and scale it to the size of your step.
Very important! Hit Ctrl > A (or the appropriate command on your operating system) and select Scale. This applies the scale so that the array modifier doesn't get confused.
Switch over to the Modifiers tab in the Properties panel (looks like a wrench) and select Add Modifier. You should see one that says Array under Generate. Click that one.
Create an Empty (Shift > A > Empty). It can be any one of the options you want, we will be able to delete it later. I selected a Cube.
Move the empty object to where you want the offset of the step would be. I just set mine with an X and Y of 0, and then I set the Z to 1. That will be the offset each step will take.
Scale the empty object to how you want the steps scaled. If you do not scale it, the array modifier will just place blocks upon blocks; you want steps. I scaled mine to 0.8 which looks pretty good in my opinion. Do NOT apply the scale! It is needed for the array modifier.
Go back to the cube object and to the modifiers tab. Under Count uncheck Relative Offset and select Object Offset. Click the value box with the cube in it. It should show a list of objects. Select the Empty.
Increase the count to the number of steps you want and you should see the pyramid! Adjust it to your liking.
To permanently apply this to your object do this: Under the Array modifier click Apply. The modifier should disappear, but the object should seem unchanged. Now, you can delete the Empty.
You are done! Following my own steps I got this:

Not exactly your picture but I'm sure by adjusting the values of the empty you can get something of equal likeness :)

This doesn't leave all steps with the same size...

Oops...I'm trying to fix that right now. I'm a beginner myself, every time I set the empty Z scale to 1 it looks weird

@Sam1370 The reason it gets weird, is that it scales down from the most recent one. So if you set the X and Y scales of the empty to 0.9, the first (not counting the original, which stays the same) will be 0.9, the second will be 0.90.9 = 0.81, the third will be 0.90.9*0.9 = 0.729 and so on.

This would have been my way... It works fine if your array is in say, Z,  and you scale the Empty S-Shift-Z in object mode. All the steps have equal depth - The array elements pick up the XY scale. ,,Maybe the OP wanted  a manifold mesh, though?

@DuaneDibbley Got it, thanks. If anyone has a solution, please edit my answer. :)

If you want each step to set back the same distance and to rise the same height, 1 way I like

Add a plane
subdivide it into as many segments as you need.
Extrude along the z axis a fixed distance.  In the example, I use e.2
deselect the outer ring of faces
Repeat steps 3 and 4 until done

If you want to use a rectangle, then use edge loops rather than subdividing.  You can have rectangular steps that way.  You don't have to make each step the same height.

A faster way is to inset faces.  1) add a plane. 2) extrude. 3) inset. repeat steps 2 and 3 as desired.  By using numerical values for the inset and extrude, you can precisely control the setback and height.  This also creates fewer faces.


text:
cant move a single vertex

Hi i'd like to know how to move just one vertex, i need to change the position of a vertex but when i select and move  the other vertex come together. I just started blender yesterday and today is my attempt to try model with tutorials but it still very hard!! i need to do what this guy did at https://www.youtube.com/watch?v=dgUx8v6u7tM 3:24
EDIT The Proportional Editing is already disabled

There are two main ways that more than one vertex can move when you have only one selected . 1) you have proportional editing switched on. 'O' toggles it. 2) You have the results of a subdivision showing in Edit Mode.. This looks like 1.

Possible duplicate of Why can't I transform faces, edges, or vertices without transforming the whole object?

Most likely you have double vertices. So you actually move a vertex, but there are 2 vertices connected to edges in the same spot which is why you select the wrong one. Try to select all and press W > Remove Doubles

@Duarte Carefully observe the menu bar. It would say Proportion Size if proportional editing were enabled, wouldn't it?

True, you are right. Now that you mention it, upon closer inspection the second 3D view does seem to indicate lots of overlapping or duplicate geometry

yes the  the Proportional Editing is already disabled :S i dont know what is hapenning , i need to do what that guy did in the video

@MrZak First,thank you so much for your reply, can you also tell me how to select All? without clicking every vertice?

the 'A' key toggles between selecting / deselecting all, and another thing to check is if you have snapping enabled (little Magnet icon in the bottom header menu) and / or an option right next to that menu that allows you to 'auto-merge' vertices that get snapped to each other. Good luck!

@MrZak omg you solved my problem!!! as Shiprex told me to press A i select everything and then i ´pressed the key you mentioned >W>Remove Doubles and it worked!! thank you so much i was stuck in this problem and finally i can keep going on now :)!! Thank you all for the replies Shiprex,Duarte,Leander and Robin.

I dont want to be anyoing but is there a specific reason you are using 2.79 (unless your GPU does not support newer OpenGL)? You should at least be on 2.83 LTS. If it is for learning 2.91.2 should be fine too.

You might have proportional editing on. If you want to use it you have to press G and then move MMB  up to shrink the size of the area.


text:
I clicked on Mirror object but it went to a wrong place
Can someone help me wiith this? I need to mirror this "eye" object to the right side < , i select all by pressing A and i clicked on Mirror option , but the object mirrered down and not side as it should be , look:

it should be like this:

And i cant UNDO the item i mirrored because it cannot be selected , i tried crtl z but didnt work too, for so many times i closed blender and opened again thinking i did something wrong , but i dont wanna do it again :S can someone tell me how to undo this too?

After some testings I figure it out - this must be your case, I think.
Before you use any modifier, ever apply transformations.
I rotated my mesh in object mode and applied the mirror and I got a bad mirror.
But after applying the rotation I got the desired mirror.
See the image below:

i didnt find option here to reply to your asnwer i will do in the comments section here! i thank you  A LOT for your help because it worked just fine now it is where it should be!!!


text:
deativate doubles
this is my third day with trying to learn how to model on blender and every time i get a new problem . I am trying to model this face with this tutorial , i had a problem with doubles yesterday , today i am having the same problem , even if i click the verticle and press W remove doubles , when i press E to extrude , it shows doubles again. Why doubles activates automatelly? is there any way to deactivate it ? this is realy annoying is always preventing me to go further with the tutorials, yesterday i had to close and open again and start all over the same project because i got stuck . i am following this tutorial here > https://www.youtube.com/watch?v=86JiuZpbi_w , the part where i am stuck is at 5:57. this "double" thing is killing me

And i needed to undo this because its wrong. but i did undo so many times after i did this, that when i press CTRL Z nothing happens :S pfff i didnt want to start from zero again , it has been realy hard to reach to this point, watched so many tutorials so far and only this one was helping me but i got stuck again

Doubles aren't a feature you activate, you are creating them, either by mistake or out of carelessness

You are confusing extrusion e and grabbing g.
While extrusion generates new geometry, grabbing and rotation just displaces or rotates existing geometry.
The portion of the video you mention uses grabbing g and rotating r, thus creating no new geometry.
To delete vertices you don't want, you can just press x or undo. Please keep in mind, that there is an object mode undo and an edit mode undo.
Remove doubles only works when vertices are in the same place (share x,y,z coordinates) otherwise you can only use x.
PS:
You probably never need to start from scratch, your mesh can be cleaned up quite easily.
Modelling a human head can be very challenging, I would suggest you put this on hold and do another tutorial on modeling in the meantime. I can recommend Andrew prices for example.

Thank you so much, you were right i did it wrong and wasnt able to realise he just moved >.< thanks for the keys tip too and this video is absolutely for me


text:
Missing properties in properties window

Hi guys, I don't know how it happened, it might be some shortcut that I don't know about. Everything is okay when I open up a new project but when I load my previous file it looks like that.
Also, I have a problem with modifiers.

It just disappeared after deselecting the object. My bad. But modifiers still won't work and there's a few of them.

The Curve Modifier is Red because you have not entered a valid curve into the Object box. If you click into the Object box and nothing shows in the drop down then there are no eligible curves in your scene.

Most tabs in the properties panel are only displayed if the active object is a certain type. If there is no active object, most of them will be hidden, as you have discovered. It's a bit uncommon to have no active object, but it is possible; deleting all objects in the scene, or creating a new empty scene are two ways. It's also possible to set it in python (bpy.context.scene.objects.active = None), and indeed some addons will (intentionally or otherwise) introduce such a state.
Similarly, not all modifiers can be applied to curve objects. Hence, not all modifiers are available in the drop down while a curve object is selected.


text:
Is it possible to do a Rigid Body chain that needs to split at a certain frame?
Is it possible to have a Chain made of individual links that is being controlled by rigid body physics to split on an exact point on an exact frame?
I have a chain around a character and in the center of the chain there is a "padlock" type device, I want it to open and let the chain fall mid animation. Can this be achieved in Blender with rigid body physics or does everything have to be animated by hand?

Yes - you can animate the properties of the rigid body constraints to effectively disable the link.
For example, here is a chain of cubes, linked together with a series of Rigid Body Constraints - each set to a Stiffness of 40. At a certain frame the keyframes Stiffness drops to zero, splitting the 'chain' :

The produces the following when animated :

That's exactly what I need! But do I need to apply constraints to every chain link? I'm asking because I never used constraints before.

@Pherion Yes - you'll need to add constraints to each chain link - however, it's quite easy to do by selecting all your active rigid body chain links, going to the toolbox panel (T), clicking on 'Connect' while they are all still selected, setting the Type, and changing the Connection Pattern to "Chain By Distance". Blender will then automatically create a constraint linking each member of the chain to its closest neighbours.

If you change the properties of any one constraint that you want to apply to all the others, then select them all first, change the setting, then right-click the setting and select 'Copy to Selected'.

Ah, thank you for this information. Not a whole lot of information about this topic online and I didn't saw anything like a "pin" feature like in cloth sim to do what I wanted. So this should help others also that may run into this same issue.


text:
How do I Replace Faces with .obj?
I've been trying to export .obj Minecraft worlds with custom .json and .obj models for every block by editing jmc2obj code and it kinda worked.
Then thought of doing something different but I don't know how to do it, I have a theory of what could make this work, (something like McPrep's Mesh Swap
My idea is to replace each individual face for another model, the way it would work is by using the face's normal lines as a way to tell blender to replace and center the model

Since it is replacing faces we need 6 objetcs one for each face

(for this block all faces are the same)
for example, if the face normal is facing at +x the face gets replaced by the object "stone_brick +x" or if it is facing at -y it gets replaced by the object "stone_brick -y" and so on until we cover all 6 faces
this would only work for cubes as for different models it shouldn't work, like fences, anvils, and any other model that has more than 1 face per axis

Parent the Objects to the Cube then in the Cube Mesh properties select Duplicate and Faces. https://docs.blender.org/manual/en/dev/editors/3dview/object/properties/duplication/dupliverts.html

@rob it worked! I just need to find a way to hide the plane and the object without hiding the duplicate or find a way to make duplicates into a mesh

cool! select the parent  :Object ‣ Apply ‣ Make Duplicates Real

oof I didn't get a notification or I would have replied earlier, anyway now I'll start creating the script so it's just 1 click action


text:
how to breakdown this line of code to create an add-on ? bpy
how to breakdown (breakdown, apportionment) this command line ?
CODE LINE:
bpy.ops.object.duplicate_move(OBJECT_OT_duplicate={"linked":False, "mode":'TRANSLATION'}, TRANSFORM_OT_translate={"value":(0, 2, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":6.11591, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":False, "release_confirm":False, "use_accurate":False}) to create an addon, from these instructions, I would like to have a couple of controls, text boxes that influence how many times to repeat operation.

number of times it doubles
axis where the duplicates are placed ( X ,Y ,Z )
relative offset ( X,Y,Z )
confirm action end

My problem is like breaking down that line of code in the necessary parts to convert it into an add-on.
I would like to have a couple of controls, text boxes that influence how many times to repeat operation.

I do not understand break down this line. Do you want to replicate the ops command without an operator? If you know how to make an addon and got the command, what information are you looking for?

You can find examples of creating add-ons and operators here:

As you can see to make any script an add-on you only need to add the information about it at the top:
bl_info = {
    "name": "name of the add-on",
    "author": "Your Name Here",
    "version": (1, 0),
    "blender": (2, 7, 9),
    "location": "some location",
    "description": "description of the add-on",
    "warning": "use warning",
    "wiki_url": "url of development or contact",
    "category": "corresponding category",
    }

Most likely you will want to create an operator for your add-on(read the comments please):
bl_info = {
    "name": "name of the add-on",
    "author": "Your Name Here",
    "version": (1, 0),
    "blender": (2, 7, 9),
    "location": "Space Menu",
    "description": "Some description",
    "warning": "use warning",
    "wiki_url": "url of development or contact",
    "category": "Mesh",
    }

import bpy

class SomeOperator(bpy.types.Operator):
    """Operate"""
    bl_idname = "mesh.some_operator"
    bl_label = "Some Operator"
    bl_options = {'REGISTER', 'UNDO'}

    some_int = bpy.props.IntProperty(
            name="Some Int",
            default=2,
            description="some description",
            )
    some_value = bpy.props.FloatProperty(
            name="Some Value",
            default=2,
            description="some description",
            )
    # Properties you define here can be adjusted in the history panel after
    # the operator is used. you can find more about them at:
    # https://docs.blender.org/api/current/
    # you can use them in the operator with 'self.' so in this case you
    # can access the property some_value as self.some_value

    @classmethod
    def poll(cls, context):
        return context.active_object is not None
    #The above bit describes circumstances that the operator is available in.
    #In this case it is only available when some object in the scene is active.

    def execute(self, context): #This is what happens when you execute the operator
        # you can use other operators here that you see in the info panel
        # you can google each one you see for more info on how it is used
        for i in range(0, self.some_int):
            bpy.ops.object.duplicate(linked=False, mode='DUMMY')
            # I found info on bpy.ops.object.duplicate in the documentation:
            # https://docs.blender.org/api/2.78a/bpy.ops.object.html
            # that came up on Google when I searched for 'bpy.ops.object'

            bpy.context.object.location.y += self.some_value
        # note that I use Python function range() as well as for loop
        # you can learn more about Python at: www.python.org or www.w3schools.com

        return {'FINISHED'}

# Registration

def register():
    bpy.utils.register_class(SomeOperator)
    # in order for it to work you need to register the operator

def unregister():
    bpy.utils.unregister_class(SomeOperator)
    # and unregistered it for it to be properly deactivated without the need
    # to restart Blender.

if __name__ == "__main__":
    register()
# This bit is only needed for it to work if you run it as a script as opposed
# to saving it to a file and installing it as an add-on

We only registered an operator and no UI for it so it is only possible to call it from the Space menu searching for it's bl_label, that in this case happens to be 'Some Operator'. You can adjust the properties after the operator is called in the history panel or in the F6 panel. You can just run the script in Blender, however you can also save it to a file with .py extension and install it as an add-on.

@Nazgûl the code in answer does emulate duplicate move (to some extent) and adds a property to repeat.


text:
Can't Copy Paste Mirrored Pose
I am following this tutorial but when I reach this part part at 19:38 I press Ctrl + C it copies but when I press Ctrl + Shift + V nothing happens.
A little menu appears on the side with Flipped on X-Axis selected but the right side doesn't copy the left side.
What am I doing wrong?

please share your file: https://blend-exchange.giantcowfilms.com/

i added to the post @moonboots

In order to perform any kind of mirroring operation on your bones the names on the left and right side of your rig must have identical names, other than the L/R indication. All the bones on the right side of your armature have '.001' at the end of the names left over from being copied at some point. Remove the .001 from each of the names on the right side so they match the left side and you will be able to paste the pose mirrored.

Thank you so much!! i renamed the right side and tried again and it worked. I couldn never imagine this was the problem! you sved me a lot of time!! thank yo.

As said by Macklehatton, your bones have bad suffixes, they should end with ".r" (or "_r" or ".R" or "_R"...) if you want Blender to understand that you want to mirror. Your left bones are correctly named, so you should delete all your right bones, then select the left bones and go to Armature > Symmetrized. The new bones will automatically be called with the good suffixes.

Thank you so much!! i renamed the right side and tried again and it worked. I couldn never imagine this was the problem! you sved me a lot of time!! thank yo.

Nice, I didn't realize what symmetrize actually does. Looks like it only works if the existing bones already have an L or R in the name, which can be added to an unlabeled rig with AutoName Left/Right in the same menu. That was probably why I didn't understand what it does. I've been looking for this feature recently, thanks.

Yes, Symmetrize makes the process a bit simpler than before   ;)

it happens to me too and I followed a good tutorial by Sebastian Lague

Hello, thanks for taking the time to answer the question. Could you add a little more information about the actual workflow ? It's better if you don't resort to linking an external video since it may not be always available in the future.


text:
How to move just one side of bones?

Hello,
Can someon helçp with this? I need to move just the left side of the bones , but the right side moves as well, i have no idea how i activated this. I will add the file in the post

Your character still has an active mirror modifier. If you want to solve the problem, select your character, in the properties tab apply the mirror modifier, then shift select the armature, press Ctrl P and choose "with automatic weights".


text:
How do I set Maximum emission strength?
Is there a way to set the Maximum strength of a material using nodes?, I tried this thinking it would make any values higher than 10 to be set to 10
so, with my logic this would "work" because the maximum value possible is 10 but the value is 76.3, and because it's higher than 10, then 76.3 gets converted to 10.
but clearly I am doing something wrong because it doesn't work :/

As the name implies the Maximum operations picks the maximum of the two input values, meaning it chooses the greatest of the two.
In your case by calculating the maximum between $10$ and $76.3$ you obtain a resulting intensity value of the highest input, hence  $76.3$.
From what what you describe you seem to want the opposite operation. If you set it to Minimum it will pick the smallest value of the two, effectively limiting emission to $10$, or whichever value is lowest.


text:
mirror modifier duplicated my body
I need to mirror the changes i am doing in the weights of my character from the left side to right side, but when i clic to add mirror modifier , it duplicates the whole body

It's not clear why mirroring if without Mirror modifier you already have full mesh. Do you want to mirror only weights? Do you want to substitute existing half of mesh with the mirrorred part?

i want to mirror only weights i paint

Then either remove half of the body or use mirroring vertex groups (provided that bones are named accordingly), see https://blender.stackexchange.com/questions/9390/how-can-i-mirror-weight-painting and https://blender.stackexchange.com/questions/44882/how-to-mirror-copy-existing-vertex-weights

With the Fast Carve Addon it is simple to use.
Download the addon here
Just weight paint one side. In the object mode -> Tool shelf -> Fast carve -> symmetrize. Click on the axis need. (If you have painted on X axis click on the X axis. It will symmetrize on the negative X axis).


text:
How to stick a curve (with shape keys) on rig?
I used curves to do my character's eyebrows and gave them some shape keys. But I didn't know that I coudln't give them an armature (the one for the character). Is there a way to keep the shape keys and making the curves followings the rig?

You can't assign curves to armatures directly nor can you weight paint.
Only workaround I know is using Hooks
You can either select your armature then enter Edit Mode on your curve, select all desired vertex and assign a hook, or manually add a hook modifier and assing the vertex afterwards.
You can hook to the whole armature, or you can hook to individual bones. Matching rotations will be an issue, but it should keep any shape keys working.


text:
Transfer vertex colors between objects
I need to vary the vertex colors of a mesh using simulation data (generated using a tool named Paraview).
I imported the mesh and vertex colors in an X3D file, but the vertex colors correspond to one instant in the simulation only.
I'd like to load the vertex colors for the other simulation instants as well (e.g., 3 s, 6 s, 9 s, etc), assign them to the mesh at different keyframes, and animate the result.
I've tried importing an X3D file for each instant (obviously very cumbersome), but even then I struggle to transfer the vertex colors from one imported mesh to another. I did this just to get some results, but ultimately I'd like to have just one object with different vertex color sets that I can assign at different times in the Blender animation.
Does anyone know how I can do this (preferably without loading extra meshes, like I've tried)?
Thanks!

Do the different instances of the object share mesh data, like do they keep the vertices in the same local positions and stuff?

Exact same mesh. The only thing that changes is vertex color In the future, maybe vertex coordinates will change also (to capture deformations), but even then the mesh topology should remain the same.

So vertex colors are part of the mesh data, so it might be possible to assign them each to different shape keys?

It would seem! But so far, nothing. Trouble is, I can access vertex colors only by loop index (bpy.data.objects[].data.vertex_colors[].data[].color). Loop indices aren't unique (because vertices of neighboring loops are shared) and they aren't the same as the unique vertex indices (for which I have data). I can access vertices by their unique indices (bpy.data.objects[].vertices, but when I do I can't seem to access the color data... Sorry if this sounds confusing :/

I see what your saying yeah, that's really weird. I hope someone comes along who knows the answer!

Got my answer from a related post: https://blender.stackexchange.com/a/119646/61149


text:
How do I create a dynamic paint obstacle?
I want to make an obstacle for a brush so if the brush's paint goes outside the box it doesn't paint

My goal is to make any faces outside the box to not get painted, I tried giving the box a brush to erase paint and it kinda works, the block on the left still gets painted even though it's outside of it,


text:
Sculpt not showing up in rendered view
Good day to all. I use Blender 2.79, and I had just finished sculpting some details on a face. So, I decided to view how my (blender) face would look in rendered mode. But, when I switched to rendered mode, it only displayed a plain UV Sphere!

Sculpt Mode
Rendered Preview Mode
Thank you to all!!!

It is because your mode is set to sculpt. Change your preview/render to object mode instead of sculpt mode.


text:
Can you make a mesh follow another mesh with Cloth Sim?
Basically, I have a mesh that is being controlled by Rigid bodies and another one by a Cloth Sim that is pinned.
Is it possible to have the pinned part of the cloth mesh follow the other mesh that has rigid bodies?

Not sure what the problem is.  The simple solution to your problem as I understand it is to parent the cloth modified mesh to the rigid body mesh.  Then, the pinned vertices will follow the rigid body.

What you can do is to link the pinned of the vertices and the rigid body to a bone.
Create a bone and apply the metarig to the cloth with empty groups first.

After this, delete the Bone vertice group and copy its name to the name of the pinned group.

Now parent the bone to the rigid body(select the bone first).
And there you go.


text:
Vertices—loop indices vs. unique indices
I need to set the colors of vertices from data generated by third-party simulation. To do this, I need to access the vertices by their unique indices with the Python API.
I can do this with bpy.data.objects[].data.vertices[], but there doesn't seem to be a color attribute there that I can set. I can access (and maybe set) vertex colors with bpy.data.objects[].data.vertex_indices[].color, but it seems that vertex_indices gives me the loop indices (which are not unique, as neighboring edge loops will generally share at least one vertex).
Can someone clarify how to do this (access vertices by unique index and set color)?
Many thanks in advance!

In Blender, Vertex Color maps don't assign a single color to each vertex but instead assign a color to each vertex of each polygon, as described in this answer by zeffii.
As you noted, loop indices are not unique. So if you want to assign a color the vertices by their unique index you would have to create a mapping of vertex indices to loop indices, i.e. for each polygon, map poly.vertices to poly.loop_indices:
import bpy
from collections import defaultdict

obj = bpy.data.objects['Cube']
col = obj.data.vertex_colors['Col']
polygons = obj.data.polygons

vertex_map = defaultdict(list)
for poly in polygons:
    for v_ix, l_ix in zip(poly.vertices, poly.loop_indices):
        vertex_map[v_ix].append(l_ix)

Once this is done, vertex_map will be a dictionary with the unique vertex indices as keys and lists of loop indices as the values. E.g. something like this for the default cube:
{ 0: [0, 8, 21],
  1: [1, 11, 12],
  2: [2, 15, 16], ... etc.
}

To assign the colors, you can now loop over the dictionary and set the color for each loop index of each vertex:
# color vertices 0 to 3 in red, all other vertices white
for v_ix, l_ixs in vertex_map.items():
    for l_ix in l_ixs:
        if v_ix in [0, 1, 2, 3]:
            col.data[l_ix].color = (1, 0, 0)
        else:
            col.data[l_ix].color = (1, 1, 1)