Darkman
-
Posts
77 -
Joined
-
Last visited
Posts posted by Darkman
-
-
you have 20k brushes , thousand of patches and entities in your mission ?
thanks shadow/sotha... if there really is no limit, this might explain how johannes manages to have (more or less)ever single stone in his map built by an own brush or patch (instead of only using fitting textures)... haha, even f.e. a singe stair seems to be made of more patches/brushes than other fm's as a whole
by the way, is your mission still in progress, shadow?
-
just another question:
as far as i know, there is a entity-count limit of about 8k.
but is there also a limit for patches/worldspawn?
thanks!
-
A very nice mission!
- looks pretty (esp. poly count not too high and also not too low; good usage of colored lights )
- has atmospheric cutscenes/"events"
- offers a smooth gameplay (meaning f.e. that important objects, like keys, where not hidden that good, that they become almost unfindable)!
so: at least in my eyes this mission is a little jewel! it was a honour to play it!
-
ahh, you mean shadowhide, i for me never had problems with him . but i know some topics which you are talking about...
and also when i gave some advices somebody fought them directly.
to say this again clearly: if i say something its an advice not criticism.
yes, i meant the one and only, the master of shadows himself!
oh guys, this was only some kind of fun. i did not aim for really "warning" anybody
by the way: hey shadow! *wave*
-
WTF?
did i miss something? is johannes working with anohter editor/game? all those screens with original tdm-stuff?
oh, and... don't feel sad but... these visuals won't satisfy "mr. S"... *cough*
-
As Nielsen74 above but bind a flame to a candle and bind the candle to a holder. You can now change the skin on the flame.
i have allready tried that. basically, this does work properly but there are also some problems occuring: f.e. the candle then has some kind of clipmodel whereas it does not collide if it's moved. so, you can stick a broadhead arrow in it as long as it's standing still but if you move it around itself, it won't collide with walls, etc. strange...
beside that, frobing the holder won't extinguish the flame - but that's not the biggest problem.
oh, these are the results if the candle is set to a model. if i set it to a ~adtm:mover_candle entity instead, it's even worse, as relighting the candleflame will also spawn a new candle with the originalskin that substitutes the one i placed before...
i hope that this was somehow understandable... well, maybe i will have some time to see what i can do here today evening...
-
evening guys!
i need help in the following task:
changing the skins of attached models that are spawned at runtime.
example: one of those atdm_candleholders (this entity includes 1 holder, 1 candle and 1 candleflame; candle and candleflame are spawned at mapstart).
it's easy to change the skin of the holder, as it's immediatelly accessible in editormode; the skin-spawnarg helps here. but it's not possible to do the same for the candle/candleflame, as they don't exist before runtime and there is no "skin-spawnarg" for attached entities...
so how to change the skins of the candle/candleflame?
ps: haha, hey, shadowhide! *wave*
-
[...]
I think I've contributed my share for TDM for the time being. I think I've now put all the ideas I had in my mind on the DR canvas. It is time to leave the floor for new mappers. I hope my works will inspire others to make new high quality maps.
I'll be around, but mapping will be a definite no no until I regain my motivation. Godspeed for everyone contributing to TDM.
heaven, earth and hell... NOOO!!!
well, but it's indeed better to quit (mapping) for some time instead of "burning" out... however, i will miss you (on the editors' side), you really built some pretty maps.
Don't stay off too long! *wave*
-
[...]
2. for what do we need this...thief was ever a fun game on its own way...if you would like to have a ranking and ach. -> COD 1 to black ops
and a ranking of singleplayer missions is senseless i think
100% signed!
-
hey melan!
wtf, all those screenshots/building-progress after 24h only?
really looks like a pretty example for what may be possible within a short peroid of time! my editing sessions always feel like spending 24 hours to simply construct a piece of paper or a waterglass...
-
oh, sounds like an interesting idea!
-
<LI>Fixed Desktop Composition Disabling code (got broken in x64 builds)
nice! Disabling code really works again now!
thanks!
-
@Darkman: Btw, instead of "triggering" the entities to hide/unhide them, you should use the $entity->hide() and show() script events in the script function that you are calling from the location triggers. That way their presence does not depend on their current state (or things can get out of sync for whatever reasons).
// Makes this entity invisible. scriptEvent void hide(); // Makes this entity visible if it has a model. scriptEvent void show();
yeah, that's even better as possible errors will be merged when leaving/entering a zone again. sounds reasonable... thanks!
i have allready rewritten my testscript/testmap, works like intended
-
Hey I think I figured out how to use that "Print Screen SysRq" key you were discussing:
Nudge nudge wink wink
*cough*
-
Well, I just hit print screen, then copy/paste in photoshop/gimp.
Would have to take a close look at the map to see why it's doing that. As far as I can tell it shouldn't. Something is weird.
BTW, letting a team member look at your map and try to track down the issue might help with performance issues mod wide
@ print button:
ouch! i have heard of this "formidable" button but i thought the screen would immediatelly be saved somewhere but i never found out where... but if i got this right, in fact the screen is only loaded in memory, waiting there to be pasted... /facepalm
@ issue:
hm, maybe not the worst idea
well, is any team interested in looking at my testmap to investigate this "phenomenon"?
-
As I alluded to in your other thread, I believe maybe the bounding box of those trees probably sticks ino the inside of the house, even though no visible part of the model does.
Would have to see a top down editor shot to confirm, but it is quite likely. People rotate trees for more variety/more natural. Then the bounding box is a bounding diamond. But terrain is still square, the diamond doesn't fit well...
unfortunatelly i don't know how to take a DR-screenshot without downloading any suitable programms from the net before. however: the separating wall on the shots has a thickness of 8 units in DR.
- one of those outdoor trees truly penetrates this wall on its outer side; it stops very close (~ 2 units) before raching the inner wall face
- the other tree does not even reach the wall; it stops at least 24 units before the outer wall face
=> but both trees are rendered even if the player sits in the indoor area...
well, we could discuss this endlessly. but no matter if it is the engine's fault or not and no matter if it's possible to derivate any rule here or not: at least mappers should be alerted as tall entities come close to a small leaf-border if there is another leaf behind - but mappers should check their maps with 'r_showtris x' anyway...
just keep my warning in mind, as we all "lose" if maps suffer under unnecessary performance hunger
-
It's possible that the bounding box of the model is sticking into an area that is still open. That is the ONLY reason I can think of that the model would not be culled if the geometry is properly sealed and portalled.
If so possibly rotating the model so the bounding box doesn't cross areas might help.
f_s's will do it if they extend into an open area or is only a little part of them is visible the entire f_s will show. Up to author to divide them up as needed
well, the engine would render such a func_static under those circumstances, that's surely correct.
however, fs's may also be rendered by the reason i mentioned above. i figured out, that the chance for such "render-errors" raises especially in relation to the thickness of leaf-brushes and the entities' tallness and position:
- the error mainly occurs when a small distance between leafs/leafborders (in my case: one box at grid size 8 = 8 units) meets with tall objects (in my case: largest version of a pine with leaves) which additionally are located close behind to such a small leaf-border (in my case: ~a gap of about max. 5 meters).
- the chance raises even higher, when such a leafborder is drawn by diagonal brushes, rather than by straight ones.
but do not regard this as an exact rule...
-
Got a screen shot..?
Sure! This kind of error is nothing new for me - and also the reason for my recently opened thread around hiding/unhiding entities (which you have noticed or not.).
Here is an example, taken from a little nice testmap:
- Shot 1 ("outside") shows two marked trees
- Shot 2 ("inside") shows them from the other side of the wall - both are still processed...
-
@stumpy: looks like you missunderstood me.
VP's do not help here, as the error lies in the engine still rendering trees which are fully located in a leaf where the player is not in - even if all matching VP's are closed and that leaf is culled for that reason (well, except it's trees)... as i experienced, this can mainly happen where large func_statics are sitting behind but close to a leaf-border which separates the player's leaf from the one with such func_statics. so at the very end i look for a possibility to somehow force the engine not to render func_statics (under the mentioned circumstances)...
@sotha: perfect! that's exactly that i was looking for!
as a result of your link to the wiki-files, i was really able to create a testmap where trees (sitting in the courtyard) were hidded while the player was inside a building - including model, shadows and collision model. Once he left the building and so entered the courtyard, the trees were unhidden.
that will later give me to chance to optimise my map through connecting func_statics to fewer but bigger ones and still force the engine not to render these, as long as not necessary.
@both: thanks a lot! you two became my heros now
-
hi guys!
i hope that anybody can help me out... so here's the base problem:
situation: think of a map with one indoor and one outdoor area; the outdoor area contains some big trees. both areas are connected by some kind of hallway, tunnel or whatever. the task i demand help for is about hiding all the trees in the outer area as long as the player is located inside the inner area.
this aim refers to having some trees rendered even if the player sneaks through the indoor by default - although they are located in a complete different visportaled and so culled place. for the moment, just believe me that this is not caused by internal leaks but lies in the engine's responsibility. so i'm aiming for hiding the trees as soon as the player reaches the indoor area (forget the LOD-system, as this solution would require some distance) and unhiding them as he gets close to the other place.
by default, this can be done by simply triggering the tree-entities (sets "hide" to "1"); another triggering-effect unhides them. so, there should be 2 triggers in the hallway: one sitting close to the indoor-entrance and hiding the trees and one sitting close to the outdoor-entrance and unhiding them.
and here lies the problem: i'm only capable of creating triggers/multitriggers that, as soon as the player runs into them, trigger the trees. but that only changes the hiding-state, whatever it is at that moment - so if you run into the same trigger twice, that state isn't really changed after all. that's why i need one trigger only to be capable of saying "hide" and another trigger only being able to say "unhide".
of course i'm also open for any other ideas, like a script maybe of whatever... but i hope that i was at least able to carve out the problem itself...
oh and one further question: am i right that hidden objects do nearly have zero performance-impact (no polygons/shadows/cm performed as long as they are hidden) ?!
-
somehow funny... half of biker's map "vanishes", while i have the problem that on some places func_statics are rendered altough they are in a completly closed area
-
Actually it's *not* creating them that eats up so much time.
lol, yes, thats somehow right
-
That's good
It just seems that nothing really touchable has been created since one Year..
yeah... it's a pitty that creating fm's eats up so much time
-
stop! think first, post then!
yes, the engine is some years old, but for tdm it has been modified: of course the fps will even with the same amount of rendered polygons be (much) lower that in the original doom game! or did you think, that god himself (instead of your cpu) calculates f.e. the existing AI's or the stealth level? these two additional tasks allready require a lot of calculations (yes, doom surely also had AI's but they had only a simple intelligence and were only spawned in when needed)...
so don't wonder when your fps are lower than in original doom, where the hardware only had to render the pure visuals and (nearly) nothing else...
so, if you prefer pure high-end-graphics, then you are wrong here!
"ich habe fertig!"
Creating Ghosts
in TDM Editors Guild
Posted