Best branch for HLMS experimenting

[Herb]

I have an application for generating 3D procedural meshes. I'm starting to write shaders tied to the meshes generated and I'm currently using 1.9. It seems like getting into HLMS might be a good thing to do instead of using the old material system. From other posts, it would seem like 1.10 or 2.0 would be good to use as they have HLMS and the change from 1.9 to theses branches shouldn't be that bad. However, I also see that development (other than bug fixes) is focused primarily with 2.1. So, if HLMS is still getting worked on, is it best to use 2.1? I'm worried that not using 2.1 might cause more issues from the shader side as features are only really being added to 2.1. Trying to validate if that's true or if HLMS is solid enough to stay with <= 2.0. Any thoughts would be appreciated. Thanks!

[al2950]

The HLMS was created in the 2.1 branch, it is not in the 2.0 branch at all. It was backported to 1.10 but I do not know what state that port is in and if its being maintained. The HLMS is improving almost on a daily basis. However 2.1 is quite a leap from 1.9, I would highly recommend it but I would make sure you understand what might be required before starting the port!

[Herb]

Ah, that's right. I forgot that HLMS was ported to 1.10 but not 2.0. So, really it comes down to if 1.10 is getting the updates to HLMS that 2.1 is getting and the work of the port. For porting to 2.1, the big things would be changes to ManualObject and I use OgreProcedural so need to see if changes are needed there.

[xrgo]

ManualObject is working but with a few differences
OgreProcedural, I haven't used it, but if it builds... you can always convert those procedural meshes from V1 to V2. And the procedural textures should not be a problem, there's no major changes in this area apart from the efficient packing method using texture arrays

[Herb]

Well, looking at the OgreProcedural repo I see support for 1.10 and 2.0 but not yet for 2.1. But, I do see in another Ogre post someone ported some of it to 2.1 but didn't post the code. I'll have to see how much change is needed for that lib for 2.1. 1.10 should work fine for what i'm doing but not sure HLMS is getting much love on that branch. Thanks for the helps guys!

[Kinslore]

Hi !

I am generating procedural meshes too (for a terrain generator), but with Ogre 2.1 and HLMS.
I think it is working well, there is a sample describing the whole process : DynamicGeometry (I used the createStaticMesh function example). There are also some samples about ManualObject (those are in the 2.0/ApiUsage samples folder). The thing making me "thinking" it is good is this... And I didn't find the problem yet (but I think it is coming from my code, a fence is locking the shutdown process, or so it seems).

I didn't use OgreProcedural though, I can't help you on this...

But if you had doubts about the feasibility of your project, I think you can !
The thing you will have to learn are the new Compositor system (which is mandatory now, but quite powerful as it has new functionalities), and the HLMS (for your shaders, as it would be sad to use the HlmsLowLevel), to do a basic program. But If you are diving more into the code, I think the differences are not so big (from what I could see... I did 1.8.1 -> 2.1). Xrgo also has a good point with the conversion system.

Hope this can help !

[al2950]

I have converted OgreProcedural, well I have converted the core, I just have not go the samples done yet and dont have time to sort them. I can upload what I have done if you are interested.

I would not use ManualObject, I removed it from OgreProcedual. The interface to create vertex buffers, etc in Ogre 2.1 one is really nice once you have read about it and looked at the samples. There is no need for ManualObject, infact it may hinder you as ManualObject has to make assumptions. Having said that it is really useful during a porting process!

[Herb]

@al2950 - I would LOVE any code you could upload on this! My procedural code is independent from both OgreProcedural and ManualObjects, so I have flexibility. I'm generating 3D trees. So, I end up making the OgreProcedural's TriangleBuffers for each branch (where the extruded branch geometry is stored), then append all of them together where I loop through the set adding the positions/texture coords/index/etc to the manualobject. It was just cleaner and easier than the raw buffers when I wrote it. But, again, I can re-write that routine to not use a ManualObject, so the code would be very welcomed.

[al2950]

@al2950 - I would LOVE any code you could upload on this! My procedural code is independent from both OgreProcedural and ManualObjects, so I have flexibility. I'm generating 3D trees. So, I end up making the OgreProcedural's TriangleBuffers for each branch (where the extruded branch geometry is stored), then append all of them together where I loop through the set adding the positions/texture coords/index/etc to the manualobject. It was just cleaner and easier than the raw buffers when I wrote it. But, again, I can re-write that routine to not use a ManualObject, so the code would be very welcomed.

My public branch is here;
https://bitbucket.org/al2950/ogre-proce ... ch/Ogre2.1

However I will need to push my latest changes. I will do this tonight @~21:00 BST (British Summer Time)

[Herb]

@al2950 - Sweet! I'll look for the changes tonight from you. Thanks again!

[al2950]

Done;

https://bitbucket.org/al2950/ogre-proce ... ch/Ogre2.1

And an hour early