-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow material inheritance from groups or instances on default materials #41
Comments
I had a look at the model and it looks like your material is applied to the group instead of the surface itself. when selecting the surface both materials are set to the default material. It looks like if the default material is selected, the element can inherit the material from the group level. I'll check if I can retrieve this material setting on group level using |
@kirabo I implemented a Material property on group and on instance level. This property will reflect the material you applied to the group. The surface's material properties will remain empty (or default) because that's what they are set to. |
bug fix ADD TO Surface FromSU if (string.IsNullOrEmpty(mbackName) && string.IsNullOrEmpty(minnerName) URef elem; |
Hi @kirabo I think I get your point. What you are asking for is raising a question of data integrity on my end. The job of this library is to represent the SketchUp Model as closely as possible as it is provided by the C API. Therefore I do not consider this a bug because this is how the data is returned from the C API. Inheriting materials from the group level is an interpretation done by the SketchUp Application. For example if SketchUp would from now on allow a single color only, let's say red, this libraries job would not be to override all materials with a red color. That's up to the application interpreting the data. I can imagine adding this feature as an optional setting when loading the model, so you are aware of the fact that this is more of an interpretation than the data stored in the model. Let me understand one thing: where are you trying to use this? In what context are you using the library? If you are using the Dynamo components I'd rather add this interpretation there. |
import to twinmotion not bug my application is unity runtime import skpfile |
There is one other issue you should be aware of, which are the components. If a component has default materials applied, in sketchup they are overwritten by the instance material. If you have two instances, one with a red material and one with a green material - there is still only one component in the database. Therefore I cannot override the material because it's either red or green. You get my point? |
@kirabo can you test the above branch and give me feedback please? |
yes fix done,thanks 👍 |
could someone post a sample how to correctly assign material to surface, as for me it doesnt work. |
@PauliusVa I just checked: applying materials to surfaces isn't implemented yet but I'll add this. |
@PauliusVa do you want to give this branch a try please: https://github.com/moethu/SketchUpNET/tree/feature/facematerials |
@moethu i have some issues loading assembly file: Seems it is missing another .dll file. any ideas what could be missing ? |
doesnt seem to work, or am i doing smth wrong. |
no link FaceBackMaterial in group?
//Function is
//static Surface^ FromSU(SUFaceRef face, bool includeMeshes, System::Collections::Generic::Dictionary<String^, Material^>^ materials)
SUMaterialRef mback = SU_INVALID;
SUFaceGetBackMaterial(face, &mback); //Error mback is 0x00
SUStringRef mbackNameRef = SU_INVALID;
SUStringCreate(&mbackNameRef);
SUMaterialGetName(mback, &mbackNameRef);
//test file is
1.zip
The text was updated successfully, but these errors were encountered: