In the Cycles roadmap under UI implementations there’s this …
Auto sync BSDF color and viewport color
Needs some algorithm to deal with mix shader hierarchies, to find the good diffuse node
IMO this feature shouldn’t get developed [wasted developer time on]. It’s perfect as it’s now. If you really want a viewport color you go and set one yourself.
This automagically determination of final viewport color from a complex shader tree will never be good. For me it just feels like a feature i will have to fix 90% of the times manually.
Id rather swap it around and in 10% of the cases set the viewport color manually it aint that hard.
Though if he’d really want to implement this, I hope that it’s not like it is in BI. BI just choses the diffuse color of the last selected material node, which can be slightly annoying if you’re messing around with specular masks or just complex node setups in general.
thanks, vote no! on proposition #85823472384782349
I don’t want that back it was messy. I hope folks vote No and brecht sees this and take the vox pop in consideration. guess this feature has very low prio anyways.
I think its both no and yes. My opinion is that it would be nice to have it as it is now, but by default the viewport color should be linked with the diffuse one. And maybe it would also be nice an option to overwrite alle the viewport material colors at once.
I’m with aermartin on this one too. Too many variables for something like this to be automated. At best get the diffuse color of the ubershader when it’s done. Seeing developers wasting time on something like this, while we don’t even have proper object/wireframe colors on the viewport, which is a whole lot more useful, would be very frustrating.
In general, I agree that it would be a bit of too much effort for little gain. On the other hand, having built-in texture (Bricks, Checkers, etc.) previews in Solid, Texture or Material mode would be a very welcome addtion.
@IMI I saw in mailing list or was it sunday meeting notes, Sergey is working on video textures for cycles. A friend of mine/colleague did a py script that changes texture on frame change. it worked for his cycles rendering with image sequence as texture. So if you really need it there’s a hacky way of getting it to work already.
But yeah it’s pretty much a big deal to tackle I suppose, especially to get it to load/offload quick on GPU vram. or how it’s gonna be implemented. Something like that is needed beacuse you can’t load like 2000 frames of 2048x2048 texture seq to the gfx card, some smart way to read/unread maybe with a buffer … I’m confident Brecht/Sergey will come up with an awesome solution
@@eugenio_jr I don’t think it’s a waste I’m just way to happy as it is already. if this is implemented there’s no “going back” to like it’s now because all objects will have automagically viewport colors set. I don’t want the messy viewport color hell I experience in BI, I don’t know how other feels about that. But me it’s more cluthered when everything has its viewport color I rather like it greyish then the really important meshes/objects I set a unique viewport color myself.
@andreu@Jonathan L in that case only in textured or material mode. not in solid but yeah that’s a better feature to implement.
If it does mean changing current solid mode i do not agree, but if he’s talking about better ogl visualization when you choose “material” draw mode that could be fine, not a high priority though, preview render does the best job. Being able to see right mapping and procedural texture in the viewport, that’s would be cool! As already said by other users.
it was messy. I hope folks vote No and brecht sees this and take the vox pop in consideration. guess this feature has very low prio anyways.