IDEA: Terragen Quotient or TQ value of a scene for defining how fast a scene is.

[cyphyr]

Ok here's my idea (must be the time of year or something)

The Terragen Quotient or TQ value of a scene.

For the non mathematical (that's me, I had to look up quotient to check) go here.

The idea basically is to have a system that tells users how complex (in terms of render time) a scene is by comparing how long a scene takes to render compared to a default scene. For the purposes of this I'm using the benchmark 52.tgd from the 3d Speed Machine site (direcct link to the scene here) but as long as we all used the same base scene it should work. It would even work with the default scene that loads with a clean TG install.

Here's how it should work.

Step 1: Download the agreed default scene and make a render without changing anything in the scene. Write down the time it takes and convert it into seconds.
Step 2: With any other scene, one you may be wanting to share on the forum for example, once it has rendered, write down the time once again and convert into seconds.
Step 3: Divide the result of step 2 by step 1 to get your TQ (it may be the other way about, this is where my brain needs a little help)
Step 4: When you publish an image or post a tgd also mention the TQ

If we all perform the same steps then we would have a way of knowing the relative complexity of each scene. So if my scene takes six times longer than the default scene on my system, then it "should" take six times longer than the default scene on your system. Of course I realise there are a stack of reasons why this will not be close to 100% accurate but nonetheless I'm sure it could be a useful comparative tool.
Once again this is not for telling each other how fast the scene rendered in, but to show how much faster (or slower) than the default scene it renders in; this information is useful.

What do you think? Am I barking up the wrong tree or could this be developed into something useful, Maybe add it into the render data at the top of the final output ...

Cheers

Richard

[choronr]

Great idea Richard, it will be interesting to follow the feedback on this.

[Oshyan]

Unfortunately I don't think this is actually a practical indicator of "complexity" so much as it is of "things that are difficult to render" and/or "people who use high render settings". For example, if you took the default scene, added a Power Fractal with small Lead-in scale and high displacement, and then added a Reflective Shader with Raytraced Reflections, you would have a scene that would take a fair amount of time  to render at high detail, yet it's obviously pretty simple in terms of technical complexity. Then you have the problem of people who use e.g. Detail 0.5 for an equivalently complex scene as another artist who prefers 0.75 or even Detail 1. Yes, you could have people report their settings and try to compensate, but it would quickly become unreasonably difficult to do so with any accuracy. There is also the problem of varying render resolution, which you could solve by having people create a reference version of their render to a standard render resolution, but if that's not their target resolution it could be  a waste of time, too.

Honestly I think something simple like "number of active nodes" might be a better initial indicator of complexity. Though I will say I've seen a lot of node networks that seem to be created in lengthy experimentation sessions where ideas tried early on are not cleared away before later ideas are tried, and so in many cases there are lots of nodes contributing little or nothing to the end result. Still, it would be an easy metric to calculate, and even if it doesn't tell you anything really solid about "complexity", it could be interesting to discuss and see in a somewhat analytical fashion how x number of nodes translates into x image.

- Oshyan

[cyphyr]

I think maybe the idea of complexity was the wrong starting point.
The idea really was to have a valid answer (well valid-ish) to the oft asked and answered question of "How long did it take to render that?" The answers given are basically meaningless since as everyone has a different system. However if I know a scene took three times as long as the default scene, it's a fair guess that the same ratio would be valid for the same scene on my system.
Is that a better way of putting it?

Cheers
Richard

[Oshyan]

Ohhh, I see what you mean. So sort of an index of "relative rendering difficulty"? Well, again this is going to depend rather heavily on people's settings, so any conclusions drawn would have to be tempered by knowledge of that. So if someone uses detail 1, and their render took 10 times longer than the benchmark, it may be more like a scene that takes 4 times longer if you had detail at 1, say. But even working out those kind of direct relationships between detail and render time multiplier can be tricky.

- Oshyan

[Matt]

Ohhh, I see what you mean. So sort of an index of "relative rendering difficulty"? Well, again this is going to depend rather heavily on people's settings, so any conclusions drawn would have to be tempered by knowledge of that. So if someone uses detail 1, and their render took 10 times longer than the benchmark, it may be more like a scene that takes 4 times longer if you had detail at 1, say. But even working out those kind of direct relationships between detail and render time multiplier can be tricky.

I don't think people care about factoring those things out. Sometimes they just want to know how long it took to make it look as good as it did (including the settings that were used), so Richard's normalized render time quotient is useful for that. In other words, it's just about factoring out your own computer.

Matt

[TheBadger]

However if I know a scene took three times as long as the default scene, it's a fair guess that the same ratio would be valid for the same scene on my system.

This statement makes sense. I would like to see it happen, if possible.

I don't think people care about factoring those things out. Sometimes they just want to know how long it took to make it look as good as it did (including the settings that were used)

Yes! But its more than that, isn't it? Users need more ways to map terragen2, we need a better view of the practical boundaries. Tuts help with understanding the limitations and best methods when building, the idea here would help with understanding the best way to finish.

[Matt]

Hi Badger, I was only talking about the "TQ" Terragen/Time Quotient idea and how it should be calculated. I didn't mean to say that the other settings aren't important generally.

[cyphyr]

Hi TB
I think your "cross threading" here.
My suggestion of the TQ rating of a scene has little to do with how to create any specific scene, we were chatting about that in the tutorials thread, but rather as a way of comparing scene to scene. If someone posts an image one of the questions that often comes up is "how long did it take to render?". It's a valid question but the answer is next to useless unless everyone has the same computer rig. The TQ of a scene gets round this by giving a relative answer. IE, this scene took 5 times longer than the default scene.
I have no idea how long a particular scene will take to render on your computer but I can tell you that it's 5 times longer than the default on my rig. It's likely to take 5 times as long as the default on your rig. All you need to know is how long the default scene render on your rig and your good to go.
I do realise that their are plenty of other factors but as a ball park figure it may prove useful.
Cheers
Richard

[jaf]

I don't know, but ..... maybe a program that parses the xml file (tgd) and calculates/assigns "weighted" values ........

Long and difficult project.  Heck, developers still have problems making an accurate progress gadgets.  For example, take Windows Explorer.  Do a deletion of a large group of files.  You may see something like this:  8 minutes left, 8.4 minutes left, 12 minutes left, 40 seconds left.......  And when finished it actually took 1 minute and 39 seconds.  Because even though the amount and sizes are known, fragmentation, cpu loads, etc., can impact the time it takes to complete the deletions.  So it "guesses."

About a year ago I wrote a tgd parser that created an on-screen report of all the objects, shaders, camers, etc.  It showed names, positions, etc. -- information I deemed valuable.  I wanted to create some tools that could do global translates or cut several displacements with a quick choose and give it a percentage, like 90%. 

Still seems like a good idea, but it's on the back burner with a bunch of other ideas that are probably worthless! 

[Oshyan]

This is really what the benchmark scene exists for. If people put their benchmark time in their signature, and then always posted the render time of their scenes, the problem would be solved.

- Oshyan

[Tangled-Universe]

All we need now is a decent benchmark scene

The tricky thing is:
With the free edition you can't really make "challenging" benchmarks. 3 populations, AA3 and 800x600 are the "craziest" things you can do, beside detail @ 1.
Rendertime-wise this is good, benchmarks will be relatively short.

However, I think the majority of people posting here use the deep edition and generally use more than 3 populations, RTO with AA>3 and greater resolutions. This way the benchmark isn't representative anyway.

Perhaps two benchmarks need to be made for this.

I think that posting benchmark times in the signature is a very good idea.