Hello
I created a simple plane in Blender and I have assigned a grass PNG image under the material modifier.
When I upload it to Speckle, the plane does not show the grass image.
I may have missed some steps?
Thanks
Doug
Hey @Doug , welcome
I’m afraid you aren’t missing anything. Speckle doesn’t yet support the transmission of texture, material or other forms of raster/binary representation of objects.
Thanks Jonathon and hopefully Speckle will support these in the future 
For me full material support would be one of the most important features.
Is this on a to do list or a low priority thing ?
EDIT
Found the other texture thread.
1 Like
It is highly requested for sure. That usually gets our attention.
Fun (not fun) fact is that every piece of software we support handles materials uniquely so it will need a dedicated effort just for this. Right now, there are a number of other engineering quality efforts underway that DO span all connectors, so future efforts will be so much easier to pull off
1 Like
Sounds great.
Basically (PBR) Materials should be pretty easy.
Textures and Diffuse, Reflection, Transparency, SSS, …
Just that for some 100% means full transparency while for others means opaque,
same for Self Illumination color, for Reflection some use IOR values while others
prefer a (user error prone) Metallic Slider, some still ignore PBR, …
Maybe we need a USD upload at one point.
(For me basically the IFC of the 3D DCC world and thankfully more and more
widely supported in 3D and CAD Apps.)
(3D App Connectors do a USD export/conversion which they stream up
to Speckle ?!?)
Not to say you are wrong, but
Probably not.
I meant Materials could be pretty easy - and it should be that way.
I am aware it isn’t (standardized).
So I can only imagine Speckle getting an own fundamental Material System
or Definition and Connectors doing translation when up or down streaming
from/to local App “dialects”.
But isn’t that was happens for BIM geometry and data already too ?
Yes and no.
A lot of the complexity is magically made simple by the fallback display mesh, which is pretty fail-safe; a 3d mesh is a 3d mesh everywhere. A fallback material is going to be visually and instantly unsatisfactory. We are quality-obsessed at Speckle; this is a better-than-perfect solution where a pragmatic compromise makes sense universally.
My gut feeling only, but I suspect a good enough render solution wouldn’t be - either way when we get to it, we’ll sweat blue blood until it’s good.
1 Like
Ah,
so just use OpenGL (Metal, DirectX, Vulkan) representation/shaders …
Hmmh,
when I think of Vectorworks just using the Preview Resolution from the
Resource Manager Icons for their “Shaded” Visual Mode …
Maybe that’s all not that easy
OK, I would be already happy if it can reliably keep/translate Material Naming
and keep a lossless Exchange without destroying Materials overwriting/definitions
on each local parties side.
Speckle Viewer is ok to use just Diffuse Color.
Or maybe an average color from the diffuse texture … and transparency textures
and …
Argh, the reality is so complicated …
1 Like
I agree with @jonathon about materials not being an easy topic to get right.
I find this table useful in determining a possible 'Speckle PBR Model". Disney’s Principled PBR use to be the OG when it comes to PBR standards and I rememer some time ago, rendering libraries aiming to satisfy it in their implementations
Speckle Viewer is ok to use just Diffuse Color.
I strongly disagree with this. Whatever material model we end up using, the viewer should also do it’s best to satisfy it inside or outside of the underlying three.js implementation.
I do believe that Speckle needs a better material model, preferably satisfying one or multiple existing standards
4 Likes
OK, I agree.
My priority is in App exchange, but it would be cool to have materials
inside Speckle too of course.
2 Likes