will you buy this?
Wouldn't buy it. Why don't you offer it for free? Establish a user base first, worry about monetarization second. If I were you I'd even open source it, then earn some cash by providing "premium support" or some such. That's a proven model.
You mean something like Assimp? Why would I buy something that's already available for free?
Absolutly not. If there is a library that is free and I think it is useful I'll use it. If there isn't I'll write my own solution.
No. Even with assimp, you have to handle everything yourself. Mine would be like (infact mine would be based on assimp) :You mean something like Assimp? Why would I buy something that's already available for free?
Model.load(path);
And
Model.render();
Model.setanimation("name", animationtype.loop);
Mine library is not like assimp. It makes the process of using assimp very easy. It handles all animation stuff and you have to just pass the name of the animation and the library will play it on the model.
Wouldn't buy it. Why don't you offer it for free? Establish a user base first, worry about monetarization second. If I were you I'd even open source it, then earn some cash by providing "premium support" or some such. That's a proven model.
Well I think I am going to do this.
To everyone -
Thanks for your reply and feedback.
1. I have come to prefer custom file formats for the engine. The content pipeline handles all the conversions and what not, and the fileformat for the engine is designed in a way that almost all the engine has to do is blockread from the file to CPU/GPU memory. Obviously this means that I can write my own (very simple) loader.
2. I feel that animations and rendering are a both very "intimate" things of an engine, and they are definetly s.th. that I wouldn't want mixed with my model loading/importing code. How is the included rendering code supposed to interact with my material system, my lighting (defered, forward, clustered, ...) and my render state batching? How is the animation code supposed to interact with my CPU skinning, or my GPU skinning, or the animation of various non-skeletal properties like light colors, particle effect properties, sound effect volumes, ...?
1.okayI wouldn't buy/use it for two reasons:1. I have come to prefer custom file formats for the engine. The content pipeline handles all the conversions and what not, and the fileformat for the engine is designed in a way that almost all the engine has to do is blockread from the file to CPU/GPU memory. Obviously this means that I can write my own (very simple) loader.2. I feel that animations and rendering are a both very "intimate" things of an engine, and they are definetly s.th. that I wouldn't want mixed with my model loading/importing code. How is the included rendering code supposed to interact with my material system, my lighting (defered, forward, clustered, ...) and my render state batching? How is the animation code supposed to interact with my CPU skinning, or my GPU skinning, or the animation of various non-skeletal properties like light colors, particle effect properties, sound effect volumes, ...?
2. It is just in built renderer for users who prefer to use it. It will give you animation and rendeing data if you want to do all things (not all) by yourself. (It is like :
Struct animationdata
{
float length;
string name;
std::vector<keyframe> keyframes;
Animationtype type;
//...
}
Model.load("name");
animationdata = Model.getanimationdata("name" or index);
K
And samething for rendering).
Anyways I will make it free as everyone is suggesting me to do that.
Hi.
I think the offered potential solution is a kind off 'wrapper' between the (assimp) library and a engine, where in a lot of cases the engine would take care of this
The problem is you're trying to write a one-size-fits all solution for an application. Not just a library that loads a model (like Assimp) but also gets it on the screen, so you're locking in users into how things are formatted and function. Basically you're offering a platform, which can be problematic if a user wants to do something different. And you aren't going to get buyers unless if there are a lot of features that sets it apart from free/open source competitors.
I think you'd do better if you wrote plugins (for profit) for an already established and mature platform. E.g. write something useful for Unity and sell that.
Okay. Thanks for your feedback.The problem is you're trying to write a one-size-fits all solution for an application. Not just a library that loads a model (like Assimp) but also gets it on the screen, so you're locking in users into how things are formatted and function. Basically you're offering a platform, which can be problematic if a user wants to do something different. And you aren't going to get buyers unless if there are a lot of features that sets it apart from free/open source competitors.
I think you'd do better if you wrote plugins (for profit) for an already established and mature platform. E.g. write something useful for Unity and sell that.
