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

Switch to Unity Packages ? #15

Open
melMass opened this issue Nov 19, 2020 · 3 comments
Open

Switch to Unity Packages ? #15

melMass opened this issue Nov 19, 2020 · 3 comments

Comments

@melMass
Copy link

melMass commented Nov 19, 2020

Hi,

I have just tried to transform the plugin into a proper unity package, I'm about to test it further:

https://github.com/melMass/com.sidefx.houdiniengine

@watsonsong
Copy link

Good work! I think package is a better way to distribute the houdini engine.
Hoping the SideFX will continue support this unity bridge. This repository has been no commit after the Epic invest SideFX...

@melMass
Copy link
Author

melMass commented Dec 3, 2020

Yes me too...
I'm not sure if it's related to the investment but the Unity bridge is always ahead in features, but behind in integration, which is strange given how easier it is to extend Unity vs Unreal.
But I think it's because Unreal is used by many non-technical artists whereas in Unity no one holds your hand (which I prefer for my use cases)

@ghost
Copy link

ghost commented Mar 3, 2021

nice work with the package manager format, +1 that SideFX should switch to this. They have 2018.x as a minimum version, and that supports packages.

just throwing out an idea (might explore it though its low priority), I think a refactor of HEU_Defines to make use of a ScriptableObject for any unity asset references (like the default shaders) would be a lot friendlier to customization (for example swapping the default shaders with SRP compatible shader graphs).

There would need to be some work done to have it detect the SO asset via AssetDatabase or automatically create it within Assets if it is missing, but it is entirely possible (very similar to how the SRP scriptable objects work)

It could also hold the other values too, as that avoids having to re-merge future changes or modify the package. It could likely also just be a yaml or json file somewhere within the project's assets folder too.

Similar could probably occur with heu_settings.ini with where it is located, that will go on version control ignore lists for sure. (I'm not really sure what the significance of it being a separate ini is, unless it is some legacy stuff)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants