Skip to content
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

280: ATTR_ directives written for hidden objects #514

Closed
tngreene opened this issue Dec 31, 2019 · 3 comments
Closed

280: ATTR_ directives written for hidden objects #514

tngreene opened this issue Dec 31, 2019 · 3 comments

Comments

@tngreene
Copy link
Collaborator

@tngreene tngreene commented Dec 31, 2019

Current if Landing Gear has some material properties or other ATTRs, Wheel will get them too. I'm not sure how I feel about this. After all, if you want some material effect to cascade down to effect the children, you'll need it across your split parent too, right? And it would be much too difficult and defeat the purpose if you had to manually figure out what material properties and other ATTR_s to copy and paste to Wheel.

I don't know though. The goal was that "animations would be split across the two OBJs." We never talked about material properties.

@arb65912

This comment has been minimized.

Copy link

@arb65912 arb65912 commented Dec 31, 2019

Just my opinion. I do not think there is a need to children objects materials needs to be inherited from a parent.

Gear and wheel are two separate objects and animations are linked but nothing else as far as material.
Most of the animations in my case are done using bones, bones and animated objects are in one collection, this is the simplest for me.

Of course I understand that others might like animations to be split across objects.
I just think that some features might cause more harm than good in overall picture.

Thank you Ted for continuous fantastic work on the exporter!

On a side note, I am using 2.80 exported for my current project and all works great (minus particles system mentioned by Ted but I did not test it yet)

@danklaue

This comment has been minimized.

Copy link
Collaborator

@danklaue danklaue commented Jan 13, 2020

I agree. Material ATTR should not be inherited from parents. I use animations split across objects.

@tngreene

This comment has been minimized.

Copy link
Collaborator Author

@tngreene tngreene commented Feb 28, 2020

So, to be more specific about what the bug is - the WYISWYG promise that ATTRs should not be written for hidden Objects is broken in several places right now. This makes this bug actually related to #538 , #536 , and #423.

Although I couldn't figure out what Material Properties ATTR_s can be written for not visible Objects right now - I did figure out 1 case ATTR_manips!

# 0 ROOT
	# 1 Mesh: thing_with_manipulator_split_parent
	ANIM_begin
	# translation keyframes
	ANIM_trans_begin	test
	ANIM_trans_key	0	0	0	0
	ANIM_trans_key	1	1.00474	0.86466002	-3.34055996
	ANIM_trans_end
	# MESH: thing_with_manipulator_split_parent	weight: 0
	ATTR_manip_drag_xy	hand	0	4.94999981	0	0	6.71999979	0			
		# 2 Mesh: child
		# MESH: child	weight: 1
		ATTR_manip_none
		# MATERIAL: Material.001
		ATTR_shiny_rat	0.5
		TRIS	0 372
	ANIM_end

I think the solution is to, during collection, set a "visible" flag - which takes into account subcollections it is contained in, default False and use that instead of complicated tests about export_animation_only and it's viewport status.

The rule, after all, is very simple. Not Visible = Only ANIM_ allowed

@tngreene tngreene changed the title 280: Split-animations exports parent ATTR_ 280: ATTR_ directives written for hidden objects Feb 28, 2020
tngreene added a commit that referenced this issue Mar 8, 2020
…t get shared across split animations
@tngreene tngreene closed this Mar 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.