I have two cubes, with one of them being duplicated link (aka Instanced).
however, when Applying a Subdivision modifier on my main one, it's not being shown on the duplicated one. I want to work with one that is straight and the second a lil bit rotated (matching a reference). But this for some reason is not possible? or is it?
I have two cubes, with one of them being duplicated link (aka Instanced).
however, when Applying a Subdivision modifier on my main one, it's not being shown on the duplicated one. I want to work with one that is straight and the second a lil bit rotated (matching a reference). But this for some reason is not possible? or is it?
I have two cubes, with one of them being duplicated link (aka Instanced).
however, when Applying a Subdivision modifier on my main one, it's not being shown on the duplicated one. I want to work with one that is straight and the second a lil bit rotated (matching a reference). But this for some reason is not possible? or is it?
How to make such squash and stretch and eyelids rig of the eye?
In maya there is such setup of layers where you copy mesh of the head and the eyeball, do a skin paint it to make it squash and stetch, and then apply it as a target to the blendshape of the main geo ( https://files.catbox.moe/qflgbl.webm ). I'm not necessary asking how to make similar setup in blender, just want to know how to have 2 weight paints in the one place without a conflict
Does anyone managed to recreate instances on face in Blender geo nodes?
Like this?
That solution doesn't work . It only aligns the child object Z axis to face normal and doesn't rotate the object itself around that normal to look toward tangent vector . We need one extra input vector at least for proper rotation , perpendicular to one of the carrier face edges maybe .
Notice how old instances are being rotated radially according to poly flow and node ones are not .
Some curve nodes have both normal and tangent output and thus allows to rotate instances properly but not that mesh to point one. I hoped somebody found a workaround.
At this time, what is the best way to deal with custom sculpt brush presets ? By that I mean the following :
Let's say I am working in my current file/project, and I create a new custom sculpt brush preset while I work (for instance something with a custom falloff and/or alpha). This will get saved with the current .blend, but not as a global preference ; and it obviously won't appear in the startup blend file either, because, well, it's not in there.
Is there any clever workaround for that, which can be performed without having to close the current work session and without having to open up another file ? Like some kind of way to export any given sculpt brush preset to an external location, and having Blender load it all up on startup or by running a script (similarly to how Zbrush loads up anything from its Zstartup folder). Or perhaps something like the way Pie Menu Editor stores its custom data. Or even, having a custom build that would treat brush presets similarly to HDR/Matcaps, which do use their own special paradigm (as these are indeed saved as preferences, which is great).
The current setup is so annoying and flow-breaking that I pretty much gave on creating custom brushes on the fly, even though I actually really need them for some specific tasks.
It saves brushes from current document to separate favorites blend file and then in a new file you can append the brushes quickly from that favorites file from same tools panel.
it doesn't save a few options although like dynotopo checkbox
Yeah it seems to be the same as the one I've found. I've just started playing around with it and it seems good features-wise but also extremely bloated (to a point where I feel like clicking around to learn the features will break my own presets). The first button of the whole thing makes zero sense. Perhaps the author is not a native speaker ...
yeah. bloated like crazy. I use only save favorite and append them back feature. If you found simpler one let us know please. Too bad brushes seems couldn't be made"assets" for a new asset browser
But ... what does a "Favorite" even mean ? This term is never used anywhere in Blender (outside of the Quick Favorites shortcut) yet this addon uses it everywhere. So far the only function I actually understand the meaning of is "Save the active brush to a file", which creates a tiny blend with the single current brush stored in (which is admittedly extremely useful, and not easily doable by default I believe).
Same goes for the "Category List" - this too is a mystery made-up term ...
Mind explaining how you operate that thing in detail ?
- - - - -
[edit] Well FWIW this made me look into the default Blender library/append system a bit more. Turns out there is a weird bug/design oversight with the way brush thumbnails are handled, as for some reason, alphas packed inside a Blend do not seem to always operate, and need to be unpacked manually to be revived. Meaning that if one has "External data >pack all into Blend" turned on, even just once during the course of a project ... then all alphas from the current scene/library can become disabled.
Once that is avoided (by unticking the "pack all into blend") all the brushes from the current scene can be saved inside a .blend, the contents of which can be re-appended at any time. I just wish there was a way to force such blends to contain only sculpt brushes, as opposed to containing everything else from the current scene/work session too (models, textures, animations ...) as that would allow to easily save out the full current brush set and only that, similarly to how photoshop handles ABRs/TPLs.
[edit2] Looks like setting alphas to "image sequence" as opposed to "single image" lets them operate as packed. Ungh.
- - - -
TLDR : is there any way to save only some specific, hand picked elements from the current session to a .blend, without having to delete/purge all the other undesired elements first ?
Heard only something strong Scottish or something :) Although better than what my English would sound 🤤😁
Still when I hit plus ( add to favorites) my current brush with assigned icon appears in the right pan of "brush manager" . Then I do "save the favorites to a file" and in new blender doc I do "Append from a file to favorites . And my saved brushes appear in a "favorite" list of brushes ( somewhere beneath standard brushes) with right icons when I hit right pane of brush manager .
I left Zbrush for Blender sculpting only recently so made not that much of custom brushes . My guess "category" is for when you have them a lot but I still have no idea how to do them.
I feel there are yet a few cool options I have not explored there .
To keep the asset filter in the asset browser you need to save the blender file, but can I save it somehow for the filter be save in every blender file I open? like saving startup file
Is the "Sculpt Vertex Colors" feature set and brush available in any recent version of Blender ? Specifically 2.9x or 3.x. It used to be part of the "Experimental Features" in a few versions, but seems nowhere to be found as far as I am concerned (in stable 2.91 and 3.0). Perhaps there is a custom build out there with it ?
On a different topic - let's say a model has a Subsurf modifier assigned to it. Is it possible to have it be at a certain subdiv level when in Object Mode (for instance at a value of 3, showing the model fully smoothly subdivided) ; and then having it automatically switch to another level (specifically 1) when in edit mode, to be able to preview just a little bit of smoothing without too much of the typical Blender subdiv slowdown ?
Of course there's the option of stacking two Subsurf modifiers with one set to 1 (always showing) and one set to 2 (set to hidden when editing), but that's less than ideal. Perhaps there is a way to have a custom macro to enter/exit edit mode that would always check the state of the subdiv levels (if any) and adjust them accordingly to context ?
Or perhaps more simply, having a macro that manually toggles the subsurf modifier assigned to the currently selected model toggles between 3 and 1 at any desired time. An alright solution, but a bit flow-interrupting.
Is there a build available with progress being made on the Subdiv editing performance issue anyways ?
Hi everyone, I need help solving this issue. As can be seen from the screenshot when I navigate on the top the parent hair is not showing. This is not an issue with the children hair. I tried everything, but nothing fixed the problem. The second screenshot is what I am trying to achieve.
I've found the solution for the previous question, but now I came across another issue. The deflect emitter is affecting all hair not only the hair within the brush radius. I combed the sides of the hair with lower value and then changed the value higher for the top part and then everything was affected. I am stuck with the hair couple of days, I will be really thankful if I could get some help.
Hey, does anybody know of a method or addon to replicate the functionality from these 3ds max scripts to snap selected vertices to the closest vertex on another object?
Shrinkwrap set to closest vertex with vertex snap for transforms enabled can give that kind of result but it's all manual work with tons of fixups. I'm more interested in a one click solution. Ideally able to pick snap targets by matching topology, now that would be great.
Thanks @quockhanhlk ! Looks like it is here to stay now. Just tried it on my secondary machine but it doesn't seem to support it, can't wait to play around with it properly soon though. Exciting stuff.
Here's another question. Is there any way to access the source path that is grayed out and "almost-shown-but-not-quite" in the UV editor ?
(... or similarly, from the relevant image node, or the image node properties tab).
I quite like how Blender allows to pack/embed textures within the .Blend while still allowing for refreshes from the source images, as I believe it is the best of both worlds. But it would be awesome if I could open said sources in one click (from this shown path), as opposed to having to manually reach them in windows explorer for each new work session that involves texture editing. Just merely being able to copy the path to clipboard would be awesome and a huge time saver ...
(and of course I mean it without having to unpack)
When the texture is packed, then this original path is not longer valid and not longer editable. And so the edit box greys out. The original path is just stored for the case that you unpack the image again. The unpacking gives you also an option to unpack into the original location when i remember right. Which is the one in the greyed out edit box here.
So the answer to your question is no, unfortunately :)
I do understand that it is grayed out, but why would it be considered invalid ? Blender still uses this string to catch any updates made to the source file that the path points to on alt-R, therefore the link is very much valid and has to be stored somewhere in the .Blend ... Also, when unpacking (and by unpacking here I don't mean unpacking in the sense of creating a fresh new file from the image data, but rather unpacking in the sense of "drop the embended data and now only use the original", whic is one of the 3 unpack options), the text field becomes selectable again and has all the info I am looking for ...
A said I could very well do an "unpack - use existing", copy the path, and then pack again ; but this seems quite dangerously prone to user error.
Because the texture is physically part of the blend file now. This is what packing does. And Blender will use the internal version of this texture now. Not the one in the path, even when there is this texture still available. So the path is in fact invalid.
When you unpack the texture to its original path, then it is physically back at its place for Blender. And then the path becomes valid again. And Blender will use this version then. But when it is packed, then Blender will use the internal, packed version.
I hope my explanation makes some sense to you :)
That said, i do not recommend to pack textures. It's the same dilemma as if you pack it into a FBX file. Hard to edit, and you will at one point simply mix up the versions. As you name it, this is dangerously error prone.
"And Blender will use the internal version of this texture now. Not the one in the path, even when there is this texture still available."
As far as my experience is concerned that that's not what's happening, as it is 100% possible to have Blender pack the files (or at least, appear/claim to do so) while also have it react to changes to the external file as pointed to by the path. To me that's the beauty of it : it combines the safety of packing, with the flexibility of being able to refresh from source ...
I do understand that packing sounds like embedding once and for all, like how most formats that support embedding do. But as said that's not the only way blender operates (or seems to operate). I personally use the "Automatically pack into .blend" option, meaning that I don't have to pack anything manually - all the images get packed into the blend on save as long as they have a user, and also retain their path to source for updates. And that's the context in which the path is definitely preserved and valid, but greyed out until the user decides to unpack.
Now of course perhaps there is some terminology issue at play here as perhaps packing is not necessarily doing what it intuitively sounds like it does. For instance I may be assuming that the file in question is packed (because it says it is) while in reality it may not ? I'd have to double check but I doubt it, as that would mean that the "Automatically pack into blend" feature doesn't do anything ...
- - - - -
Edit : for the sake of absolute clarity here is a practical example showing a packed image still being live and refresh-able from source from the "greyed out" path :
I see what you mean and how it looks like. But the files are still packed.
When you modify this internal texture externally from within Blender, then this change still applies to the internal packed texture. The texure saves out so that you can open it in your graphics software, then it gets load back, and everything still happens internal. The greyed out path may even be used to store the internal texture for external modification. But for Blender this texture is still packed, and remains packed. And so the path is still invalid, and remains greyed out.
The path to the texture is: myblend.blend, as long as the texture is packed. External modification from within Blender is another chapter :)
Proof: close Blender, try to modify the texture in your folder path. It will not work. The texture is packed in the blend file.
I think you are missing my point by about a mile :D Well of course the file in question is packed, as it is what "Automatically pack into .blend" does, and both the UI and behavior indicate that it is. My hypothetical at the end of last post was only in reaction to your suggestion that if it was packed then there there would be no way to modify it externally, which is not the case. Which in turn would suggest that the packing isn't doing what it says on the tin. But it does. Haaaaaaaaaaa ! :D
Also yes, the protocol you describe does work, I do it about 10 times a day when working on a Blender project : If I close Blender, modifiy the texture in the source folder, open Blender again and hit Reload on the packed image, it does update it. Now is the image still packed for real *after this very point* or is the UI just not refreshing the packed status, I don't know - but that's largely irrelevant anyways since everything will get packed upon save after that.
Now I do understand that this behavior goes against the intuitive concept of packing/embedding therefore I suppose that this is likely where your confusion (or rather, assumption) comes from - as one would expect that any software embedding something within a file would ditch the original path as it becomes irrelevant ... but Blender doesn't. If there's one thing I've learned from using various pieces of software it is to never assume anything about a feature based on just its name :)
As for the path : I am not exactly sure what you mean by "invalid". What I observe is that :
. It is greyed out for some reason, but is somehow used by Blender to catch any edit made to the external file on altR Reload. Unless you are saying that Blender uses some other way to remember the location of the source file ?
. It shows the last used path to the file before it was packed, which is the information I am hoping to ctrl-c (regardless of it being "valid" or not. The "greyed out"/pseudo-invalid invalid nature of the string doesn't matter one bit to me - what bothers me is the way the greying out prevents me from selecting it).
@kio Ha ! is there some way to explore what an image Datablock contains ? Even in raw form.
-----
Edit : Now in all fairness there is also the topic of absolute/relative paths. At this time I have it setup to use relative paths, meaning that the path I am trying to select only partially fits my needs. But I suppose that there is a way to somehow reconstruct the full path by appending the location of the current blend file.
I think you best should ask the Blender developers here then. Looks like a bug. But I think this could even work by design, and that the reload in the menu could be connected to the Edit Externally functionality. But when you have a look at the greyed out property, here the reload button is greyed out too. The curious part is when you click at edit externally then you get a error message that you first need to unpack the texture. So for me it looks like a bug here. I am just not sure which part of it. The whole design is wicked.
Nevertheless, and to come back to the greyed out path. This original path can fit, but there is no guarantee for it. Since the texture is now packed. The old path is not longer used, it is just stored. When you pack the texture, and move the blend file to a completely different pc, then the texture is carried too. But at this other pc this path leads to nowhere then. As told, for Blender this path is currently invalid as the texture path. The actual path to the texture is myblend.blend. And this is why it is greyed out :)
Hehe yeah this is a very Blenderesque case : under the hood it is actually really quite elegant (as being able to pack while still allowing refreshes from source is truly a great design imho - it allows me to work very safely with all the advantages of working from external textures, while still being certain that I won't ever lose anything months down the line even if my folder structure changes for whatever reason) ; but the UX has inconsistencies and oddities, like the way Reload is allowed from the menu and from a hotkey, yet not allowed from the side panel as you pointed out.
The only explanation I can think of is that the concept of packing while still retaining the link to the original and still allowing reloads from it is likely a feature that has been introduced later than packing itself, and the "graying out" behavior for packed files (which is really just a UI behavior and says nothing about the so-called validity of the path itself) didn't get the design attention it deserves.
Also, my guess is that the greyed out nature of these buttons is not determined by the path being invalid in and of itself (as in : not pointing to any existing file on disc), but only by the fact that the image data currently in use is packed.
So it follows that there are really 2 paths being stored there : the internal path inside the Blend, AND the external path, just greyed out. Otherwise there would be no way for Blender to refresh from source, and the "Unpack - Use original" feature wouldn't exist.
-----
As for "Edit externally" : indeed this is inconsistent since in my case the path is valid (or shall I say : it points to a file that actually exists, and that Blender considers as source all this time, despite it displaying the path as greyed out/invalid) and I should be able to open and edit the source (and indeed I can - just not initiated by Blender, only manually). That too to me is an artificial limitation imposed by the UI because under the hood it is actually supported (as demonstrated in the video).
Ironically I am not too warm at the idea of bringing it up as an issue/dev thread, as this could lead to the reloading from source of packed files to be disabled altogether, even though it is a fantastic feature.
I have a question regarding Blender 3.1 and OBJ exports. I have a problem here that I already had with older versions Blender, but I knew how to fix it there. This method does not seem to work in Blender 3.1 anymore.
The problem is with the naming of the objects/ meshes after OBJ export. Blender 3.1 changes the names of the mesh objects contained within the file. When I have an object named e.g. 'arms_low' in a Blender file, export it in OBJ format, and then re-import the OBJ, the same object is now named 'arms_low_arms_low_arms'.
As I said, I had this problem already with older versions of Blender, but there was a way to 'fix' it. All I had to do was to make sure that both object name and mesh name were the same (object named 'arms_low', and mesh named 'arms_low' as well).
This doesn't work anymore in Blender 3.1. Even if both object and mesh names are the same, Blender still changes the object names to gibberish, or attaches the mesh name to the object name. This is very unfortunale, as it makes it impossible to use OBJs exported from Blender for texturing in Substance Painter or Marmoset Toolbag, they rely on exact naming conventions.
I made a small video to show off some of the UV techniques I use to one of my buddies and since I've never seen any tutorial or anyone use theses techniques I thought I'd share it here too. Hope someone finds this useful.
Replies
When you create duplicated link you only link object data (that is a mesh). So you need to copy modifiers to linked duplicate manually. More on how to do that: https://blender.stackexchange.com/questions/319/add-the-same-modifier-to-multiple-objects-at-once
does anyone know if blender supports vdm stamps for sculpting? trying to port over some brushes i create for zbrush into blender. thanks
No, it does not ... to my knowledge.
thats unfornate. thanks tho
another question if you dont mind. Is there a way to create a stamp/alpha that pushes up and down?
yes
thanks SnowInChina. I managed to find a tutorial showing how to achieve that. https://www.youtube.com/watch?v=S3bLgf0PTDg&t=500s
@gnoop Try using the "tangent" node, instead of "normal" for your capture attribute vector value input
I see only curve tangent node. No mesh/poygon tangent. Could you post an example please
My bad, they took the node out on the fields implementation, not available anymore
Hello all,
At this time, what is the best way to deal with custom sculpt brush presets ? By that I mean the following :
Let's say I am working in my current file/project, and I create a new custom sculpt brush preset while I work (for instance something with a custom falloff and/or alpha). This will get saved with the current .blend, but not as a global preference ; and it obviously won't appear in the startup blend file either, because, well, it's not in there.
Is there any clever workaround for that, which can be performed without having to close the current work session and without having to open up another file ? Like some kind of way to export any given sculpt brush preset to an external location, and having Blender load it all up on startup or by running a script (similarly to how Zbrush loads up anything from its Zstartup folder). Or perhaps something like the way Pie Menu Editor stores its custom data. Or even, having a custom build that would treat brush presets similarly to HDR/Matcaps, which do use their own special paradigm (as these are indeed saved as preferences, which is great).
The current setup is so annoying and flow-breaking that I pretty much gave on creating custom brushes on the fly, even though I actually really need them for some specific tasks.
(This would be for 2.9x btw, not 3.x)
[edit] : I haven't tried this yet but will do so asap : https://tingjoybits.gumroad.com/l/zLBPz
Still I'd be curious to hear any suggestions.
pior Try this one https://github.com/tingjoybits/Brush_Manager
It saves brushes from current document to separate favorites blend file and then in a new file you can append the brushes quickly from that favorites file from same tools panel.
it doesn't save a few options although like dynotopo checkbox
Heya -
Yeah it seems to be the same as the one I've found. I've just started playing around with it and it seems good features-wise but also extremely bloated (to a point where I feel like clicking around to learn the features will break my own presets). The first button of the whole thing makes zero sense. Perhaps the author is not a native speaker ...
yeah. bloated like crazy. I use only save favorite and append them back feature. If you found simpler one let us know please. Too bad brushes seems couldn't be made"assets" for a new asset browser
But ... what does a "Favorite" even mean ? This term is never used anywhere in Blender (outside of the Quick Favorites shortcut) yet this addon uses it everywhere. So far the only function I actually understand the meaning of is "Save the active brush to a file", which creates a tiny blend with the single current brush stored in (which is admittedly extremely useful, and not easily doable by default I believe).
Same goes for the "Category List" - this too is a mystery made-up term ...
Mind explaining how you operate that thing in detail ?
- - - - -
[edit] Well FWIW this made me look into the default Blender library/append system a bit more. Turns out there is a weird bug/design oversight with the way brush thumbnails are handled, as for some reason, alphas packed inside a Blend do not seem to always operate, and need to be unpacked manually to be revived. Meaning that if one has "External data >pack all into Blend" turned on, even just once during the course of a project ... then all alphas from the current scene/library can become disabled.
Once that is avoided (by unticking the "pack all into blend") all the brushes from the current scene can be saved inside a .blend, the contents of which can be re-appended at any time. I just wish there was a way to force such blends to contain only sculpt brushes, as opposed to containing everything else from the current scene/work session too (models, textures, animations ...) as that would allow to easily save out the full current brush set and only that, similarly to how photoshop handles ABRs/TPLs.
[edit2] Looks like setting alphas to "image sequence" as opposed to "single image" lets them operate as packed. Ungh.
- - - -
TLDR : is there any way to save only some specific, hand picked elements from the current session to a .blend, without having to delete/purge all the other undesired elements first ?
pior to be honest I have no idea what all those things mean . Tried to see YouTube video
Heard only something strong Scottish or something :) Although better than what my English would sound 🤤😁
Still when I hit plus ( add to favorites) my current brush with assigned icon appears in the right pan of "brush manager" . Then I do "save the favorites to a file" and in new blender doc I do "Append from a file to favorites . And my saved brushes appear in a "favorite" list of brushes ( somewhere beneath standard brushes) with right icons when I hit right pane of brush manager .
I left Zbrush for Blender sculpting only recently so made not that much of custom brushes . My guess "category" is for when you have them a lot but I still have no idea how to do them.
I feel there are yet a few cool options I have not explored there .
[edit] Moved post to the 'how to model' thread
To keep the asset filter in the asset browser you need to save the blender file, but can I save it somehow for the filter be save in every blender file I open? like saving startup file
Not that i know of. Currently you need to switch the asset library every time you load a new blend file. It always starts with internal.
Hello all,
Is the "Sculpt Vertex Colors" feature set and brush available in any recent version of Blender ? Specifically 2.9x or 3.x. It used to be part of the "Experimental Features" in a few versions, but seems nowhere to be found as far as I am concerned (in stable 2.91 and 3.0). Perhaps there is a custom build out there with it ?
Yup stable builds don't have it so you'll have to get the 3.1.0 alpha.
Both uv square and text tools can't straighten uv's with blender 3.0, is there any other option avaliable?
Edit: Textools still working!
@Defunct - understood, thanks !
On a different topic - let's say a model has a Subsurf modifier assigned to it. Is it possible to have it be at a certain subdiv level when in Object Mode (for instance at a value of 3, showing the model fully smoothly subdivided) ; and then having it automatically switch to another level (specifically 1) when in edit mode, to be able to preview just a little bit of smoothing without too much of the typical Blender subdiv slowdown ?
Of course there's the option of stacking two Subsurf modifiers with one set to 1 (always showing) and one set to 2 (set to hidden when editing), but that's less than ideal. Perhaps there is a way to have a custom macro to enter/exit edit mode that would always check the state of the subdiv levels (if any) and adjust them accordingly to context ?
Or perhaps more simply, having a macro that manually toggles the subsurf modifier assigned to the currently selected model toggles between 3 and 1 at any desired time. An alright solution, but a bit flow-interrupting.
Is there a build available with progress being made on the Subdiv editing performance issue anyways ?
3.1 branch should have the GPU open subdiv code already merged.
Hi everyone, I need help solving this issue. As can be seen from the screenshot when I navigate on the top the parent hair is not showing. This is not an issue with the children hair. I tried everything, but nothing fixed the problem. The second screenshot is what I am trying to achieve.
I've found the solution for the previous question, but now I came across another issue. The deflect emitter is affecting all hair not only the hair within the brush radius. I combed the sides of the hair with lower value and then changed the value higher for the top part and then everything was affected. I am stuck with the hair couple of days, I will be really thankful if I could get some help.
@pior its been awhile - not sure if you're aware yet, but newer daily builds has the GPU subd for viewport performance.
Hey, does anybody know of a method or addon to replicate the functionality from these 3ds max scripts to snap selected vertices to the closest vertex on another object?
Shrinkwrap set to closest vertex with vertex snap for transforms enabled can give that kind of result but it's all manual work with tons of fixups. I'm more interested in a one click solution. Ideally able to pick snap targets by matching topology, now that would be great.
Thanks @quockhanhlk ! Looks like it is here to stay now. Just tried it on my secondary machine but it doesn't seem to support it, can't wait to play around with it properly soon though. Exciting stuff.
Here's another question. Is there any way to access the source path that is grayed out and "almost-shown-but-not-quite" in the UV editor ?
(... or similarly, from the relevant image node, or the image node properties tab).
I quite like how Blender allows to pack/embed textures within the .Blend while still allowing for refreshes from the source images, as I believe it is the best of both worlds. But it would be awesome if I could open said sources in one click (from this shown path), as opposed to having to manually reach them in windows explorer for each new work session that involves texture editing. Just merely being able to copy the path to clipboard would be awesome and a huge time saver ...
(and of course I mean it without having to unpack)
When the texture is packed, then this original path is not longer valid and not longer editable. And so the edit box greys out. The original path is just stored for the case that you unpack the image again. The unpacking gives you also an option to unpack into the original location when i remember right. Which is the one in the greyed out edit box here.
So the answer to your question is no, unfortunately :)
Heya @Tiles , thanks for chiming in.
I do understand that it is grayed out, but why would it be considered invalid ? Blender still uses this string to catch any updates made to the source file that the path points to on alt-R, therefore the link is very much valid and has to be stored somewhere in the .Blend ... Also, when unpacking (and by unpacking here I don't mean unpacking in the sense of creating a fresh new file from the image data, but rather unpacking in the sense of "drop the embended data and now only use the original", whic is one of the 3 unpack options), the text field becomes selectable again and has all the info I am looking for ...
A said I could very well do an "unpack - use existing", copy the path, and then pack again ; but this seems quite dangerously prone to user error.
Because the texture is physically part of the blend file now. This is what packing does. And Blender will use the internal version of this texture now. Not the one in the path, even when there is this texture still available. So the path is in fact invalid.
When you unpack the texture to its original path, then it is physically back at its place for Blender. And then the path becomes valid again. And Blender will use this version then. But when it is packed, then Blender will use the internal, packed version.
I hope my explanation makes some sense to you :)
That said, i do not recommend to pack textures. It's the same dilemma as if you pack it into a FBX file. Hard to edit, and you will at one point simply mix up the versions. As you name it, this is dangerously error prone.
Heya @Tiles,
"And Blender will use the internal version of this texture now. Not the one in the path, even when there is this texture still available."
As far as my experience is concerned that that's not what's happening, as it is 100% possible to have Blender pack the files (or at least, appear/claim to do so) while also have it react to changes to the external file as pointed to by the path. To me that's the beauty of it : it combines the safety of packing, with the flexibility of being able to refresh from source ...
I do understand that packing sounds like embedding once and for all, like how most formats that support embedding do. But as said that's not the only way blender operates (or seems to operate). I personally use the "Automatically pack into .blend" option, meaning that I don't have to pack anything manually - all the images get packed into the blend on save as long as they have a user, and also retain their path to source for updates. And that's the context in which the path is definitely preserved and valid, but greyed out until the user decides to unpack.
Now of course perhaps there is some terminology issue at play here as perhaps packing is not necessarily doing what it intuitively sounds like it does. For instance I may be assuming that the file in question is packed (because it says it is) while in reality it may not ? I'd have to double check but I doubt it, as that would mean that the "Automatically pack into blend" feature doesn't do anything ...
- - - - -
Edit : for the sake of absolute clarity here is a practical example showing a packed image still being live and refresh-able from source from the "greyed out" path :
https://www.youtube.com/watch?v=enl4C6jL6pg
I see what you mean and how it looks like. But the files are still packed.
When you modify this internal texture externally from within Blender, then this change still applies to the internal packed texture. The texure saves out so that you can open it in your graphics software, then it gets load back, and everything still happens internal. The greyed out path may even be used to store the internal texture for external modification. But for Blender this texture is still packed, and remains packed. And so the path is still invalid, and remains greyed out.
The path to the texture is: myblend.blend, as long as the texture is packed. External modification from within Blender is another chapter :)
Proof: close Blender, try to modify the texture in your folder path. It will not work. The texture is packed in the blend file.
If the path still exists on the image data block, it wouldn't be difficult to script something...
And from a quick look at the image API it seems to be there. Guess you could just a write a 'copy image path to clipboard' operator or so.
That's actually no bad idea. And worth a try :)
Hi there again @Tiles
I think you are missing my point by about a mile :D Well of course the file in question is packed, as it is what "Automatically pack into .blend" does, and both the UI and behavior indicate that it is. My hypothetical at the end of last post was only in reaction to your suggestion that if it was packed then there there would be no way to modify it externally, which is not the case. Which in turn would suggest that the packing isn't doing what it says on the tin. But it does. Haaaaaaaaaaa ! :D
Also yes, the protocol you describe does work, I do it about 10 times a day when working on a Blender project : If I close Blender, modifiy the texture in the source folder, open Blender again and hit Reload on the packed image, it does update it. Now is the image still packed for real *after this very point* or is the UI just not refreshing the packed status, I don't know - but that's largely irrelevant anyways since everything will get packed upon save after that.
Now I do understand that this behavior goes against the intuitive concept of packing/embedding therefore I suppose that this is likely where your confusion (or rather, assumption) comes from - as one would expect that any software embedding something within a file would ditch the original path as it becomes irrelevant ... but Blender doesn't. If there's one thing I've learned from using various pieces of software it is to never assume anything about a feature based on just its name :)
As for the path : I am not exactly sure what you mean by "invalid". What I observe is that :
. It is greyed out for some reason, but is somehow used by Blender to catch any edit made to the external file on altR Reload. Unless you are saying that Blender uses some other way to remember the location of the source file ?
. It shows the last used path to the file before it was packed, which is the information I am hoping to ctrl-c (regardless of it being "valid" or not. The "greyed out"/pseudo-invalid invalid nature of the string doesn't matter one bit to me - what bothers me is the way the greying out prevents me from selecting it).
@kio Ha ! is there some way to explore what an image Datablock contains ? Even in raw form.
-----
Edit : Now in all fairness there is also the topic of absolute/relative paths. At this time I have it setup to use relative paths, meaning that the path I am trying to select only partially fits my needs. But I suppose that there is a way to somehow reconstruct the full path by appending the location of the current blend file.
Sure -
This is the image data API:
I think you can also just type
bpy.data["Imagename"]. filepath
Or
bpy.data["Imagename"].resolution
Etc.
In the python console to explore what data you have at hand.
Ah, now i see what you mean :D
I think you best should ask the Blender developers here then. Looks like a bug. But I think this could even work by design, and that the reload in the menu could be connected to the Edit Externally functionality. But when you have a look at the greyed out property, here the reload button is greyed out too. The curious part is when you click at edit externally then you get a error message that you first need to unpack the texture. So for me it looks like a bug here. I am just not sure which part of it. The whole design is wicked.
Nevertheless, and to come back to the greyed out path. This original path can fit, but there is no guarantee for it. Since the texture is now packed. The old path is not longer used, it is just stored. When you pack the texture, and move the blend file to a completely different pc, then the texture is carried too. But at this other pc this path leads to nowhere then. As told, for Blender this path is currently invalid as the texture path. The actual path to the texture is myblend.blend. And this is why it is greyed out :)
It remains curious ^^
Hehe yeah this is a very Blenderesque case : under the hood it is actually really quite elegant (as being able to pack while still allowing refreshes from source is truly a great design imho - it allows me to work very safely with all the advantages of working from external textures, while still being certain that I won't ever lose anything months down the line even if my folder structure changes for whatever reason) ; but the UX has inconsistencies and oddities, like the way Reload is allowed from the menu and from a hotkey, yet not allowed from the side panel as you pointed out.
The only explanation I can think of is that the concept of packing while still retaining the link to the original and still allowing reloads from it is likely a feature that has been introduced later than packing itself, and the "graying out" behavior for packed files (which is really just a UI behavior and says nothing about the so-called validity of the path itself) didn't get the design attention it deserves.
Also, my guess is that the greyed out nature of these buttons is not determined by the path being invalid in and of itself (as in : not pointing to any existing file on disc), but only by the fact that the image data currently in use is packed.
So it follows that there are really 2 paths being stored there : the internal path inside the Blend, AND the external path, just greyed out. Otherwise there would be no way for Blender to refresh from source, and the "Unpack - Use original" feature wouldn't exist.
-----
As for "Edit externally" : indeed this is inconsistent since in my case the path is valid (or shall I say : it points to a file that actually exists, and that Blender considers as source all this time, despite it displaying the path as greyed out/invalid) and I should be able to open and edit the source (and indeed I can - just not initiated by Blender, only manually). That too to me is an artificial limitation imposed by the UI because under the hood it is actually supported (as demonstrated in the video).
Ironically I am not too warm at the idea of bringing it up as an issue/dev thread, as this could lead to the reloading from source of packed files to be disabled altogether, even though it is a fantastic feature.
(Nice Windows user name BTW :D)
Yeah, better don't wake up sleeping dogs here :D
Blender devs asking for feedback on designing texturing tools, voice your opinion guys !
https://code.blender.org/2022/02/layered-textures-design/
edit: the devtalk discussion is happening here:
https://devtalk.blender.org/t/layered-textures-design-feedback/23092
I have a question regarding Blender 3.1 and OBJ exports. I have a problem here that I already had with older versions Blender, but I knew how to fix it there. This method does not seem to work in Blender 3.1 anymore.
The problem is with the naming of the objects/ meshes after OBJ export. Blender 3.1 changes the names of the mesh objects contained within the file. When I have an object named e.g. 'arms_low' in a Blender file, export it in OBJ format, and then re-import the OBJ, the same object is now named 'arms_low_arms_low_arms'.
As I said, I had this problem already with older versions of Blender, but there was a way to 'fix' it. All I had to do was to make sure that both object name and mesh name were the same (object named 'arms_low', and mesh named 'arms_low' as well).
This doesn't work anymore in Blender 3.1. Even if both object and mesh names are the same, Blender still changes the object names to gibberish, or attaches the mesh name to the object name. This is very unfortunale, as it makes it impossible to use OBJs exported from Blender for texturing in Substance Painter or Marmoset Toolbag, they rely on exact naming conventions.
Any ideas/ solutions for this?
Report it as a bug. It is one :)
Hey guys,
I made a small video to show off some of the UV techniques I use to one of my buddies and since I've never seen any tutorial or anyone use theses techniques I thought I'd share it here too. Hope someone finds this useful.
https://www.youtube.com/watch?v=0X6X-47iL0o