Ken Finlayson

Kfinla

About Me

EXPERTISE
Indie Gamedev
INDUSTRY
Gamedev

Connect

LOCATION
Canada

Houdini Skills

Availability

Not Specified

Recent Forum Posts

Unity Terrain data Jan. 18, 2018, 4:16 p.m.

seelanv
Currently the Unity plugin does not directly support Houdini heightfields as Unity terrain. As a workaround, use a convert_heightfield, which will then allow the plugin to bring it in as a regular mesh.

There is development currently being done to support heightfields directly. As for ETA, the best I could promise is sometime this year.

Thanks thats great to hear.

I still have a question though, I guess I asked 3 above.

Can the Unity HEngine plugin work with Native Unity terrains? What I would like to do is be able to just drop the terrain prefab into my HDA within unity and work with it. I have not had luck so far.

Unity Terrain data Jan. 18, 2018, 11:57 a.m.

Has the status of this changed at all? ( can Hengine work with Unity terrains now - 16.5 323 ?)

I made a simple tool to blow away any geo that is under a terrain, but sadly in Unity when I drop the Terrain into the specified slot in my HDA slot nothing happens - i would guess it is not recognizing it as geo. Is this user error on my part? should this work?

My hack at the moment is to embed an exported OBJ version of the terrain into the HDA, but that is not ideal as we have many levels and it is not dynamic if the terrain is edited.

I am going to try adding a convert_heightfeild node into the terrain input node chain just to see if that fixes things.

Also is there an ETA on when the Unity plugin will support the new 16/16.5 houdini terrains the like the Unreal ones does?

Thanks.

Stabilizing point numbers Dec. 15, 2017, 6:15 p.m.

I have come up with a solution. Migrating to using “copy to points” instead of using the “old” copy stamp sop and stamp functions. I am basically doing a hybrid. I am using the copy stamp to set and manipulate the $ID values. ID was always stable. I have not sorted out how to replicate this with the “copy to points” because I think you need the upstream functionality of stamping inputs. But I have migrated all the rotation and scaling to the “copy to points” sop. And because data only flows down stream with this, as long as I set the rotations and scale attribs before I disrupt things with my local override, everything is stable. Which is how I though the copy sop would work - but makes sense now that it cannot. I also seem to have gained about 3x interactivity performance boost this way, with the copy stamp only worrying about copying the right mesh to the right ID, and the copy to points doing the rotations and scaling. I will try compiling the copy to point sops soon.