Is there any support in the engine for displaying the draw calls being made?

I've looked but couldn't see anything. This would be useful feedback.

I don't think so, was already checking this in the source.

Sadly i doubt there is a way, but it's a much needed feature imo.

http://www.esenthel.com/community/printt...p?tid=2796

I wish to see Greg opinion as providing more profiler helper functions would really help us

What you can do:
-draw fewer objects
-merge some objects together
-use as few materials per mesh as possible

I could open up few contributions for performance improvement:
-auto mesh part merging when possible for fewer draw calls in shadows
-improve terrain performance rendering for auto merging terrain meshes/heightmaps
-auto merging of grass objects on the fly

This could have very good impact on performance.
However basing on the slowness of "Hardware instancing" contribution I doubt people would throw money at this.

(04-27-2014 10:08 PM)Esenthel Wrote:  What you can do:
-draw fewer objects
-merge some objects together
-use as few materials per mesh as possible

Thanks for the suggestions, I will be certainly looking at all aspects of my current level content to see if I can improve performance by changes under my direct control.

(04-27-2014 10:08 PM)Esenthel Wrote:  I could open up few contributions for performance improvement:
-auto mesh part merging when possible for fewer draw calls in shadows
-improve terrain performance rendering for auto merging terrain meshes/heightmaps
-auto merging of grass objects on the fly

This could have very good impact on performance.
However basing on the slowness of "Hardware instancing" contribution I doubt people would throw money at this.

I was kind of hoping you might meet me (and obviously others) half way by improving the inherent performance features of your engine over time. As far as I can ascertain both Advanced Occlusion Culling and Hard Ware Instancing have been on the roadmap for years. Why are they there if they will not be developed without specific additional funding, which it seems you are implying unless I've misunderstood you? Wouldn't they be better removed and simply placed on a 'funded only' development list so it's clear to everyone these will not be developed without that.

It's your engine Greg, I'm not trying to dictate what you develop and what you don't. You're in a much better position than I to determine the needs of your own marketplace, all I'm asking for here is transparency so each of us here as developers can make informed decisions.

Quote:I was kind of hoping you might meet me (and obviously others) half way by improving the inherent performance features of your engine over

Yes of course I'm working on all sorts of improvements to the engine over time.
I'm just saying that if XX feature is of high importance to anyone, then I can do it in first priority after agreeing on cost for it.
I'm not implying that those features will be developed only after being paid for.
I'm focusing on doing things that generate the most revenue, so I can have a stable income. Stable income is the crucial part in keeping up the work on the engine.

(04-27-2014 11:54 PM)Esenthel Wrote:  I'm focusing on doing things that generate the most revenue, so I can have a stable income. Stable income is the crucial part in keeping up the work on the engine.

This is true, and makes sense. While some of us really want some of the more advanced features and performance increasing techniques, it's the higher-level (dare I say 'novelty'?)features that will draw in more customers on the whole.

(04-27-2014 10:08 PM)Esenthel Wrote:  However basing on the slowness of "Hardware instancing" contribution I doubt people would throw money at this.

As someone who is investing quite heavily in this, I do find that a pretty poor choice of words, indeed.
It's sitting at nearly a thousand USD now, which, to me, seems like it is more important than anything else. Considering how many big projects have moved away for performance reasons, I think you shouldn't treat this so lightly.

Lastly, if this contribution never happens, then a bunch of people have wasted a lot of money. Sure, we've given you funding, but as someone with no income yet, I can think of other things to invest my money in.

(04-27-2014 11:54 PM)Esenthel Wrote:  ...
I'm just saying that if XX feature is of high importance to anyone, then I can do it in first priority after agreeing on cost for it.
I'm not implying that those features will be developed only after being paid for.
...

Well thats good to know but I think one of the issues facing customers is your roadmap has no development order so there is no visible sign of progression for any given item on the list. How would I know if Hardware Instancing for example was any closer to being started or make any guestimate as to when it's likely to appear. The only mechanism we see as customers to ensure its development is the existing contribution system.

(04-27-2014 11:54 PM)Esenthel Wrote:  ...
I'm focusing on doing things that generate the most revenue, so I can have a stable income. Stable income is the crucial part in keeping up the work on the engine.
...

I appreciate what you are saying about ensuring a stable income and I personally have no issue in contributing towards development of features within reason. However, I don't like the present contributions system. The one you outlined below in this thread seems a better system and more likely to entice people to part with their hard earned cash:

(02-13-2014 11:27 PM)Esenthel Wrote:  How about this approach:
-put most of the roadmap elements to the contributions section,
-assign complexity (which is estimated number of days to finish)
-calculate priority = money_raised / complexity
-I'll start working on everything sorted by highest priority like this:

Feature #1, Complexity=2, Raised=100$, Priority=100$/2=50
Feature #2, Complexity=1, Raised=30$, Priority=30$/1=30
Feature #3, Complexity=10, Raised=200$, Priority=200$/10=20

Because with this approach I'll be working on elements for less money than I want, I reserve the right to work on "element with highest priority" AND "elements of my own choice" at the same time.
So I'll be doing highest priority items, and some other elements up to my own choosing.

Additionally, very complex items, will have an extra parameter "minimum amount of raised money needed to start work".
For example, if at a moment there will be one item on the list:
Feature #1, Complexity=30, Raised=10$, Priority=10$/30=0.33
It would take me 30 days to do this, but I've gathered only 10 bucks, which is obviously not a good deal for me. So complex items, would have the extra parameter, for example:
Feature #1, Complexity=30, Raised=10$, Priority=10$/30=0.33, MinRaised=1000$
I will start working on this item, only if it has gathered 1000$ (and if at that moment it's at the top of the list).

Only very few items will have the 'MinRaised' param, which are those of very big complexity.

Let me know what you think.

I fully understand your position and I appreciate not all of us will get what ideally we might wish for. In order to grow your business you need to provide for the wider customer base and not tailor your engine to the wishes of a few. However, I think a change to the existing contribution system could help both yourself as developer and us as customers reach a better compromise.

I also want to throw in the room that the "stable income" should also be a part of the new licensing system. Having subscribed customers should ensure this.
So I think this argument is not fully valid anymore.

Nevertheless I understand that "New Feature: Facebook integration" sells better than "New feature: Much faster in some cases"

But seeing some progress on the roadmap would hold existing customers subscribing your engine.

There are ways of retreving drawcalls, however there are more than just that one drawcall integer. (DrawPrimitive, DrawPrimitiveUP, etc..). Easiest way of getting the draw call would be through out the SetStreamSource function from DirectX.

Having the source the above would be no problem. However if you don't, then I don't think you should try to get that far into it, as the solution would slow down your game, but ofcourse it would work for debugging purposes and checking states before building the release. But there are ways for you to receive the drawcalls.

Suggestion : Wait for Esenthel to decide on his own if he wants to implement drawcall count.

I also want to add that it's pretty useless to blindly reduce drawcalls if they aren't even slowing down your game.
You could group objects together, but if sending information to the GPU isn't the bottleneck, then you might actually make performance worse.

Maybe it's not true, maybe it will always be more performant (Unless you group everything into huge chuncks, making frustrum culling pretty useless). I was taught to always start optimizing the slowest parts of your program, since they will be the most useful by far.

My point is that we need a way of knowing if the drawcalls are actually reducing performance -> Stats would be nice.

(05-06-2014 03:23 PM)Tottel Wrote:  I also want to add that it's pretty useless to blindly reduce drawcalls if they aren't even slowing down your game.
You could group objects together, but if sending information to the GPU isn't the bottleneck, then you might actually make performance worse.

Maybe it's not true, maybe it will always be more performant (Unless you group everything into huge chuncks, making frustrum culling pretty useless). I was taught to always start optimizing the slowest parts of your program, since they will be the most useful by far.

My point is that we need a way of knowing if the drawcalls are actually reducing performance -> Stats would be nice.

Yes they are, and they are by a chunk load.

http://msdn.microsoft.com/en-us/library/...s.85).aspx

You've got the source, go ahead and try the difference.

(05-06-2014 04:10 PM)TBJokers Wrote:  Yes they are, and they are by a chunk load.

http://msdn.microsoft.com/en-us/library/...s.85).aspx

You've got the source, go ahead and try the difference.

But what if you don't have many drawcalls to begin with? For example, if you have an empty scene with 200 trees or so. Let's say you have 500 draw calls.

If you would instance all of those, that means they will all be done in a couple of draw calls (I guess you still need separate drawcalls for trunk/leaves?).

Your CPU should be able to send 500 drawcalls to the GPU without any problems. But if you group all of them together then you mess up your frustrum culling (If any of the trees are in view, all will be rendered even when they are outside of the camera). Shouldn't that make performance worse?

I should mention I'm a shitty graphics programmer, am I completely wrong here?