Shaderblocks: Block-based image editing
thejenkinscomic.net
Shaderblocks: Block-based image editing
1–10 of 46 posts
Re: Shaderblocks: Block-based image editing
#2Very nice ;)
Re: Shaderblocks: Block-based image editing
#3This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
Re: Shaderblocks: Block-based image editing
#4This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
Layer effects, though?
I'm still butthurt about when Blender introduced a node editor and confused me, I lost all my Blender expertise at that point. (The persistence of a vestigial old way of doing things only makes it worse, because of course I want to try to do everything without nodes, and then I don't have any guidance because all up-to-date docs and tutorials talk about nodes all the time. Nodes! Ruining everything!)
Re: Shaderblocks: Block-based image editing
#5This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
https://graphite.rs/ (still early in development) offers node-based editing, you may be interested in trying it.
Re: Shaderblocks: Block-based image editing
#6This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
https://graphite.rs/ (still early in development) offers node-based editing, you may be interested in trying it.
[dead]
Re: Shaderblocks: Block-based image editing
#7This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
Afaik there is a small photo/video editor called CameraBag which displays adjustments and filters as little boxes laid out in a row and you can enable or disable them.
Re: Shaderblocks: Block-based image editing
#8A couple of suggestions.
A clearer mechanism to indicate when a dragged component will fit into a cell of another node. Quite often when you drag the highlighted drop area is obscured by the node you are dragging.
pow(a,b) and abs(b), max(a,b), min(a,b) nodes would add a lot of functionality.
Then you could do something like.
(((1 / abs((((0 - (y-0.5)) * 6) - ((sin(((((x-0.5) * 6) + time) * ((cos(time) / 3) + 2))) / 4) + pow(((x-0.5) * 2), 3))))) / 9) + (0 - pow((1 - min(abs((x-0.5), abs((y-0.5))), pow(9, 9))))
as seen at https://c50.fingswotidun.com/show/?code=10v-6*u6*t%2Btc3%2F2...
(note - in my thing u and v are shorthand values for 0.5-x and 0.5-y respectively)
A perlin noise can add a lot too but not as trivial to add. I have a compact perlin generator in the first few lines of https://c50.fingswotidun.com/fastStackie.js which uses hashing to generate indexed random numbers, rather than a lookup table that sometimes gets used for Perlin. Feel free to use the code if you understand any of it.
Re: Shaderblocks: Block-based image editing
#9This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.
https://graphite.rs/ (still early in development) offers node-based editing, you may be interested in trying it.
Indeed, it's weird that nobody has brought node-based editing to regular image manipulation before our project, but that's our goal with Graphite. With the equally important goal of making the node aspect optional for users by building such capable tooling that it can abstract away the node graph for all conventional image editing use cases, allowing users to work purely with the WYSIWYG tools that secretly manage the node graph behind the scenes. Until they're proficient enough with the traditional tools to start learning the power of node-based editing.
That said, we've been building our engine so far with a focus mostly on vector editing. There are some raster nodes but they're pretty limited right now (no GPU support yet, more engineering to do until that's production-ready). The raster compositing and image manipulation nodes + tools + infrastructure will be a big part of the focus for next year on the roadmap (https://graphite.rs/features/#roadmap).
Re: Shaderblocks: Block-based image editing
#10A couple of suggestions. A clearer mechanism to indicate when a dragged component will fit into a cell of another node. Quite often when you drag the highlighted drop area is obscured by the node you are dragging. pow(a,b) and abs(b), max(a,b), min(a,b) nodes would add a lot of functionality. Then you could do something like. (((1 / abs((((0 - (y-0.5)) * 6) - ((sin(((((x-0.5) * 6) + time) * ((cos(time) / 3) + 2))) /…
It's super awesome of you to take the time to provide detailed feedback for a random stranger's project - good on ya!
A single suggestion:
Try using "the critique sandwich" when commenting on people's hard work - can help them appreciate the effort you've put in rather than feeling too defensive