Jump to content
The Dark Mod Forums

PinkDot

Member
  • Posts

    1171
  • Joined

  • Last visited

Everything posted by PinkDot

  1. Collision mesh doesn't have to be convex but each polygon has to be convex. Actually that's what polygon is - convex flat shape- no matter how many sides (vertices) it has. Baddcoq - you could really go for something closer to teapot shape, if you use actual polygons, not just tris.
  2. snow and architecture textures are not uploaded. Both are just started sets of textures and somehow I tend to leave things unfinished before moving to another task. But I'll upload those halftimber walls as they are, cause I never know when I get more time to do it...
  3. PinkDot

    Model issues

    Actually it's nearly exact copy except for the faces with transparency - they shouldn' cast a solid shadow so no shadow is better for them.
  4. I don't know. I'm not an expert but since they're not being rendered maybe it's easier for computing collisions to operate on polygons rather than tris.
  5. In game engines (not in 3d app) polygons have many sides but are always cooplanar. Tris = faces and have always only 3 sides. Everything which is displayed is triangulated anyway, so polycount is usually diffrent than number of tris but people tend to mix up these words ("polycount" as a word just sounds good, doesn't it?). But sometimes it's good to be aware about that diffrence - f.e. collision meshes have limit of 16 polygons, not tris. This make big diffrence, cause you can have CM in shape of 14 sided cylinder, which would have actually 52 tris (faces) as a regular model....
  6. PinkDot

    Model issues

    600 and 200 makes a significant diffrence and that's more the way I'd see it. It's a lot of shadow polygons saved but still can give some good looking shadows.
  7. somewhere in pk4s, in base folder. I believe that diffrence between shadow2 and shadow is that shadow2 has also noselfshadow keyword. I used it for cuttlery to avoid weird selfshadowing, caused by shadow mesh sticking out of the visible mesh.
  8. PinkDot

    Model issues

    They are not 1000 (and not polygons but tris - this also makes a diffrence). Big ones are +/- 500 tris. Smaller ones are less than 300. See Model Gallery for exact numbers. Only one hammer statue has more than 700 tris (because of rounded edges) - that's why it has shadow mesh. (BTW: I wasn't aware at that time that shadow mesh doesn't replace model's shadow but adds to it, I have to unsure that it doesn't cast double shadows atm). Baddcoq - did you get those polycounts from DR? It gives you total number of polygons per model, including visible, collision and shadow mesh. Not really very useful, but I don't know if it could be fixed to ignore collision and shadow mesh. While I agree that we need to optimize models, I would be careful with doing it too much. Going down from 2500 to 200 might result in shitty shadows really. I'd prefer to turn shadows off for some less significant models rather than having boxy shadows for all of them.
  9. For simple geometric models renderbumpflat is better. Or just Photoshop. Renderbump is only good for organic models. I find it better to use 3d app instead of renderbump. In 3ds max you can use cage for greater control over the direction of projecting rays.
  10. http://www.iddevnet.com/quake4/LevelEditor_Performance This link is not new on this forums (Gildoran posted it some time ago). You can find there some info on Draw calls and Batch sizes. Basically draw is a batch of polygons of the same shader and for one light only sent to graphics card. So 10 AI with 10 shaders each lit by 3 lights mean 300 draw calls. It's plenty, because 1000 is recomended maximum number of draw calls per frame. And where's the rest of rendered map? Springheel - I believe 10 meshes AI are a performance killers. Did you check them in empty room or in full map, with plenty other models and geometry with various textures? If anybody has time to do some test (sorry, I can't for a while) just check how many draw calls each AI adds to scene. There's a commnad r_showprimitive which shows draw calls number.
  11. Does it average the scale of textures? Well, if I had one texture with scale 0.2 and another with scale 0.4, I'd like the new faces to be textured with scale either 0.2 or 0.4, not 0.3 as no texture had that scale...
  12. I believe that simpler collision mesh means shorter compiling the map and smaller .cm file (so loading time should be shorter as well). But the main reason is calculating collisions at runtime. After optimizing collision mesh of my galleon, FPS jumped up from 8 to 15 at worst spots. (It went to 20 after optimizing shadows, btw). When I think of it now - maybe (I don't know - I'm just guessing) engine computes bounding boxes of models first - in that case smaller models wouldn't have that much impact on performance as big ones, but still - plenty of them will have impact on performance for sure, but not at all on the gameplay. I don't think our models were made with proper optimization in mind. Sure, polycount, shadows and collision meshes - we were aware of this. But nobody thinks about drawcalls. I'm only recently after reading some article on this. Basically every shader, model, texture, light etc. etc. causes draw calls, which are very bad for performance. Ideally every model should have one shader assigned, otherwise drawcalls get multiplied by amount of models, shaders, lights and so on... It's just easy get it out of control. But at the same time I can't see any good way of managing that in such a project like this mod - most of us don't have game developing experience, everyone here is just a volunteer, doing something from time to time...
  13. OK, my shitty Large PWN-Oxford English-Polish Dictionary is currently burning in my fireplace....
  14. Just one thought on that - how many polys does that curved arm have? If we want to go for such smooth curves we really should make much simpler collision models for them. It's very expensive in terms of performance to have collision meshes matching exactly visual models. And we don't need them to be such detailed for metal objects. Wooden things has to be more detailed, because of arrows sticking into them (we don't want to see arrows floating in the air), but as arrows break on metal anyway, we can simplify it a lot.
  15. Doily is made of paper, isn't it? (I do have that word in my dictionary... ) What Arcturus made is kind of lace, made of fabric.
  16. Hmmm... Maybe I'm wrong but as far as I understand, what Komag wants is: - clip brushes - figure out the most "popular" texture - copy it to newly created faces. The last one is the same as MMB and SHIFT+MMB, which works fine already. Why would it be error prone now?
  17. I think that's the one from Dram's mansion.
  18. Well, you can always try to build your own table if you want... And then make it func_static.
  19. Happy Birthday! Don't do any coding today!
  20. The only thing I can think of is using filter stage. No alpha map necessary - just make the background of emblem white, so it won't affect the tunic. But that obviously will make the emblem always darker. You could try add stage (with black background) for brighter emblems, but I don't know if it wouldn't be kind of selflit. (depends on brightness) Another solution would be to add extra polygons and make them exactly the same way we have hinges on the door, but that's a bit complicated... And emblem wouldn't really blend with tunic, it would look like something on top of it.
  21. OK, I thought it would ignore all other polygons, once shadow mesh is there (same as it does with collision mesh) but it looks that it adds shadow material to shadow mesh. That explains fps drop with new model. Thanks Baddcoq. AFAIR it's noselfshadow as well.
  22. That head looks great, as for the proportions and detail. But I wouldn't say it's a nobleman's head. Face is too slim, like he was starving nearly or just had hard life. Also - I'm not sure what's the age of that man. Early screenshots suggested old man, but he's getting younger and younger with more details and hair.
  23. Dmap seems to ignore a shadow mesh I added to my galleon model. It's definitely there, cause I can see it in DR. (black texture with SHADOW on it). But in game, when I turn the shadow silhouette on (r_showsilhouette 1) I can see shadow detail which shouldn't be there. (exactly same as visible mesh). And I think that fps is lower now than before instead of higher. I used textures/common/shadow material for shadow mesh. Did I forget about something?
  24. Pirate flag model will go to nautical, I suppose, so maybe nautical.mtr? Looks good, BTW. Do you paint or draw in traditional techniques as well?
  25. Thanks Fidcal, I have to check what they say on TTLG... I'm building interior with brushes and it's looking fine so far. AI fits into door, so I hope to make a small level with some gameplay in that galleon.
×
×
  • Create New...