Dungeon Master Forum

I already have a perfect creature which I paid to have animated for me (after paying for the actual creature). I needed this initial creature to get the coding done for controlling the animations, etc. You can get enough free "items" for the environment and the actual geometry of the world is easy enough to do (I can sort all this out myself). The problem I have is with the creatures. I actually had no problem paying for my "ettin" and the animations, it seemed reasonable to me and the results are bloody brilliant. The problem now is that the bar has been set very high for anyone to follow, I think this is the real problem.

From memory, as long as the poly count is below 9,000-11,000 we are ok. The actual animations required can be given if someone is interested in doing something for me. But basically its the usual - walk forward, die, attack 1, attack 2, turn left, turn right, etc, etc. For the scale and so on I can supply a tile which represents the floor for an artist to work on.

Thanks.

zoom wrote:Really shocked me the first time I saw and read that here. One virtual lamp: 50 Dollars. Ridiculous but then there is time spent and know how involved.still...

You answered your own outrage! I'm outraged that you think it's too expensive -- $50 is nothing to pay for good quality work and people deserve to be fairly compensated for being skilled at what they do.

The story goes that Picasso was sitting in a Paris café when an admirer approached and asked if he would do a quick sketch on a paper napkin. Picasso politely agreed, swiftly executed the work, and handed back the napkin — but not before asking for a rather significant amount of money. The admirer was shocked: “How can you ask for so much? It took you a minute to draw this!” “No”, Picasso replied, “It took me 40 years”.

Also ... I fear the costs would be a lot larger if it were an artist doing a clone and asking for a professional coder to write an engine. Just my 2p.

hi, I did not have the "h´ead" to answer until now.
THing is, I am relatively new to all this. Business and getting payed and so on. Gambit, of course you are rightly outraged.
It was thinking out loud from an "ignorant" point of view.

Initially it is like this: You do something kreative and do not charge money or vice versa you do not understand what work is worth. So for me I would rip myself off when doing e.g. a website (because I do not know how much to charge)
erm, hope this clears it up a bit. I have just begun to realise and think of the issue payment etc
i guess part of the compensation you get from customers could be that they come back to you.If they don´t rip you off and if you do not charge the absolute maximum. whatev0r, have a nice day

Another problem is that nowadays so many things can be gotten for free, we do not expect anymore to have to pay. At least for virtual things - in real life we are used to go to a shop, and pay for everything, from service to products.

If you want to sell your work but don't know what it is worth there are two approaches:

1) Look at similar offers by other people and what they charge.
2) Set a minimum wage for yourself and don't sell your work under that, unless it's something you can sell several times.

3D models come for surprisingly high prices, but if I look at the time I need to make them, I can understand the price. I once made a very simple human model, not even animated or animatable, and worked about 25 hours on it. If I want 5 dollars per hour, which isn't much, that is 125 dollars for a thing that looks like the wooden posing puppets that some painters use to check poses.

So if I work 25 hours and pay for a good 100 dollar priced 3D model of a human, I'm actually better off. Which makes me think again if it was worth buying Poser, a decision that I have delayed way often now. Ah well. I hope to make sword model today and I hope I can do that in less than 3 hours ...

Just for the record .... I have spent 1000s of hours on my game engine (many rewrites to further my understanding and improve it). So, if the artists are dedicated to a DM style clone then they need to pull their fingers out :O) Using your hours as an example, I have probably spent 25 hours on a single shader file (less than 100 lines of code) and my source contains 30+ shaders.

What Zyx wrote about the features some days earlier is really of some significance, though.

The game elements we love and know from DM should find a way into entombed.
Some kind of grid system maybe,
where you can put levers, pits etc relatively easy (container system) and run into walls for damage, evade spells and projectiles. This grid should be underlying and not be overly noticeable.
Controling 4 champions contrary to the 1 person 3d games. Fights should be cool and exciting.
Inventory management, input devices possible interface changes etc.

Makes me wonder how doom did all that? how is position in the 3d world being computed ( very roughly- concept wise only) in the 3d games that are out there.

What do you all think, is it worth talking about that or not?
What is the aim of entombed there? How or where can it be improved on?

Entombed is 100% grid based, like good old dm. The latest videos are shown as fps because I use the free camera to check the world, shadows, seems, etc.

If you watch the old videos you will see the old flick screen style movement.

One possible option, if you wish to get away with EVEN HIGHER poly models...
When your engine loads your file, and you 'cache' your model data into v-ram, send the data to the GFX card 4 times, 1 for each facing direction, and precalculate all your back-facing polys, culling them. Then at runtime, you simply pick the right model version to display at the right time. I know that this would make a lot of extra work for you, but the payoff would be twice as many front-facing polys at the same performance costs (except 4x the v-ram usage, but Entombed hasn't got any problems there).
I don't know if you already do, but you could also use vertex arrays to gain some raw speed. Batching your polys together would probably hold some benefit also.

I know that I ranted a bit here, but I saw the 9-11k limits posted above... some of the "free models" that I've got are well over 25-50k.
I've even got a 6-sided die that is made up of over 100,000 tris!
At least it looks SUPER REALISTIC

There is a difference between having a model for "off line" rendering and in-game rendering. 11K polys is plenty to create a creature with, I think Crysis use around this figure so thats good enough for me. When creating models for prerendered sequences artists dont care about poly count. When you create assets for a game you need to be aware of the restrictions of modern graphics cards. You definately wouldnt want a 100K poly creature for a game engine. For a single frame in a game you might render the geometry several times to do effects, shadows, lighting, animations, or whatever. Therefore, when my engine runs at 60fps and renders the view with 3 creatures in it you end up rendering millions of polys. Hope this is clear.

The discussion here isnt about anything technical or bottle knecks or whatever. I just want an artist to create some creatures for me. Thats it really.

DSE: Shall I post an artist request for you on some Computer related forums?
Maybe you're going to have some answers

You can certainly give it a go ! At the very least it will be an interesting experiment :O)

Ok... opening thread(s) right now!

Cool !

I wan't meaning to do "offline rendering"... what I was meaning was:
1) Start engine
2) Model's start to load
3) For each given model, figure out front-facing polys and send ONLY the front-facing polys to the GFX card to remember (glDisplayList, or the DX equivilant).
4) Send the data for each facing direction... do step 3, rotate model 90 degrees and repeat the front-faces check for THAT facing direction.

It is still "online rendering" just using an "offline rendering" technique to optimise it.
This way means that you never have any completely back-facing polys, and therefore you can double your total poly count due to the fact that 1/2 your polys (back-faces) are going to get "filtered out" for each facing direction. Also, even if you don't increase the poly count, it would make the engine twice as fast using your current models.

As I said above, this may quadruple your memory usage, however twice the performance seems like a fair trade-off.

I hope that I explained it better this time around

@Bones:
Isn't it so that the graphic card calculate if the poly are frontfacing before sending the poly to the pixelshader, if the polys are backfacing then the shader ignores calculating the pixelshaderdata. The same goes for if a pixel are going to be drawn at a coordinate where there already is a lower z-value than the drawn pixels z-value (I have tried this by drawing in front to back order and gained 25 % more speed). In DSE:s case he seems to have the most calculation in the pixelshader, and not in the vertexshader, so I have a hard time beliving that it would give him a posiblity to render twice as much poly:s, maybe 1/4 as much in the best case depending on how much calculations he has in the vertexshader.

But I agree with you that it would work creating a new model for every 90 degree with only polys that has frontfacing normals, but I can only see this working for nonanimated objects. In DSE:s case that are using skinning he has to calculate this before every frame that he renders instead of in the loadingsequence.

Sorry for the critisism but if you are right I could save some cpu in my own work

The bottleneck MAY be in the pixelshaders, but less verts means less work overall. Back-facing polys still need to be determined as "back-facing", so it's less work at runtime for the CPU/GPU if it doesn't need to check for back-faces every time it's drawn.

Which is honestly going to be faster... checking back-faces every time you render, OR precomputing the back-faces at loadtime eradicating the need for the extra calculations?

Animations also wouldn't be an issue... you'd just have to do the front-face checks for each frame of animation, then each facing direction. Yes, loading times would increase (quadruple the original, that's virtually instant, so it shouldn't be much of an issue), the end result is a much faster engine at runtime.

I've used this approach in my own engine, and it gave me a major performance boost (depends on the model, less back-facing polys means less gain).
I also use a similar technique rendering the actual dungeon (precompute the appearance for each possible dungeon square (every possible combination of walls, floor & roof). Then, at runtime, when I need to draw a given gridsquare, I just go "Which walls, floor or roof are active in relation to the camera?" (my camera never actually moves, the dungeon moves around IT) and draw the corrisponding 3D tile. When I switched to this method, it was 10x the performance of previous methods.



My lesson for the day: PRECOMPUTATION
Precompute whenever possible AT ALL. Be it placing a formula outside a loop making it only calculate once, instead of 1000 times. Or be it simply using addition whenever you can, it's faster. Every single nanosecond of CPU or GPU time counts, so save it wherever you can!

Lord_BoNes wrote:My lesson for the day: PRECOMPUTATION
Precompute whenever possible AT ALL. Be it placing a formula outside a loop making it only calculate once, instead of 1000 times. Or be it simply using addition whenever you can, it's faster. Every single nanosecond of CPU or GPU time counts, so save it wherever you can!

This is what I do with my Dugoma project, but more extremely. If you check out the thread, you'll see that this has it's own limits and problems - but in Entombed there might be better compromises possible. The meshes can be precomputed and stored, that should work, everything else I'd leave dynamic, otherwise one looses too many of the options a GPU offers, like dynamic lighting.

And drawing constant expressions out of loops should not be considered a optimization, but as my professor called it "competent coding". Actually most compilers should do it automatically these days ... so I guess this is why programmers do not care anymore (I don't want to say that programmers became worse - there is just no need anymore to think about this if the compiler does it for you, and this is good because it allows to focus on the real problems).

Bones - If I am understanding you correctly ... what you are saying makes no sense at all and is totally unusuable. Are you saying that I precalc the front facing polys for each possible direction so that if, for example, I need to render the creature from the side I only render the visible polys (using the precalculated 'side' model) ? That just doesnt work. How would you get an accurate shadow from a butchered model, you would need to calculate numerous (not 4) angles of the model so memory usage massively for no gain (dont even consider smooth animation). You might be able to get something going but it would not result in any performance increase when considering the other issues you face. Another point, GFX card performance is not really linear. You dont get "twice as fast" from halving the polys.

Graphics cards are very, very fast at dropping back facing polys as well (and can process millions of polys per second). I wouldnt worry about it. I can load the model once onto the card and render the same creature 30 times using some form of batching. This fits in with my lighting model, etc. This is the fastest method I have found and I am happy with it.

I dont really need help on performance, Im ok for that thanks. I need an artist.

Bones - I look forward to you getting your engine/game to have the same set of features as mine and rendering the same, sort of, quality. At that point we will be able to compare the fps we are getting. It will be interesting to see the difference. Cheers.

@Hajo: I understand that drawing constants out of loops is optimised by the compiler. What I meant was, for EG:
You have a loop from 1-100, that offsets each of your rendered grid-squares.
Instead of going (offset=number*per_square_offset) 100 times... I'd go (offset=per_square_offset) at the start of the loop and then use addition to increase the offset (offset=offset+per_square_offset) with each iteration. I was saying, for loops, use addition WHENEVER you can. It's not the easiest path, but it's by far the faster.

@DSE: I see what you're meaning.... shadows would become more cumbersome to calculate. That's one of the things on my "to-do" list. So by me saying this to you, I may have actually saved myself a whole lot re-writing later!
Sorry that my suggestion wasn't helpful at all

I too look forward to getting my engine up to YOUR standard
It's gonna be a LOOOOOOOOONG road.

Bones - Good luck and keep us upto date with your progress.

Just added a new video to youtube with some updates for my clone. its not officially back on, I am just completing some of the parts of the engine.

Anyway, here is the link, please change to 480p for viewing and click full screen. It runs at 1920x1080 on my machine but youtube has reduced the res somewhat -

http://www.youtube.com/watch?v=Ti-jlMUY0mE

Cheers.

Magnificent this video dse I waits with very big for impatience your clone especially to stop not works him

same as i feel, very awesome DSE

Thanks chaps.

Looking good

Super duper work; I do hope you manage to get something out of all your efforts, it would be a shame for it to simply remain a tech demo. (?)

Thanks all. Just so you know I have emailed about 15 freelance artists asking if they will help with the graphics (paid for their time). I want to (at least) get one playable level done and released. Hopefully one of them will help out.

Just a note on the video - the water bouyancy was coded by me (physx doesnt do bouyancy) so that was a challenge :O)

I have also just got my AI for 3d environments working so things are moving again.

Especially abandon not the project continue in ........