HMart
-
Posts
1541 -
Joined
-
Last visited
-
Days Won
9
Everything posted by HMart
-
IMO i think this is a bad idea and personally i will never play any mission from anyone: One charging money to unzip a TDM mission, is not only that in very bad taste is also very suspicious in my book. Two anyone locking their content (among plenty of others that is not his or hers) so other mission makers can't see, play and learn from them, specially when those are making or made free missions and are sharing or shared their work openly. IMO a healthy community is a sharing community.
-
For what is worth my condolences as well, be strong.
-
You are right, my pseudo code was something i wrote in the moment and was not really well thought out, was just a direction to follow nothing more. Hum didn't knew triggers performed a distance check every frame? Are you sure about that? I always thought they just checked for collision. Yes the player behind the bush is a problem in that case, but i can also think of a solution to that problem, just do a visual check by the AI, if a bush or various are on the line of sight, check if player is inside any of them, if it is, disable polygon checking for that bush and permit the usage of something like i said above if not use the normal view check, of course all of this will make the AI visual system more complicated and demanding not sure if the custe /benefit is good.
-
I don't see why it would not be possible but a "shadow light" is really not on the engine so anyone would need to implement one at the engine code level, perhaps using a blend light could work? Btw thinking about this subject of hiding on bush's, i have a idea for a script, don't know how feasible it is tho. Like was said you can already hide in a large enough bush, but is all or nothing, so if I wanted to simulate bush density or hiding amount, this probably would work: First i would define a special bush entity (using a entity def file), where i would put all the necessary variables that i needed, for example a bush density value. Second i would make a script to control it, warning, you or anyone reading this needs to know basic scripting/coding to understand this, ok lets go on, on that script i would define a new game object ( object specialBush{...}; ) then write code to detect if the player is inside it: I think this calc would demand a loop running every frame, so to save on performance i would instead use a trigger that i would bind to the bush entity on the editor: pseudo code ahead: if player triggers the trigger do if self.distanceTo(&player1) == 0 and self.distanceTo(&player1) < self.getsize() do // zero means you are exactly at the center of the bush model, getsize() gets the size of the Bounding Box of the model so we don't waist time running the code if the player origin is outside the model bush_density = self.getfloatKey("density"); if bush_density > 0 and bush_density < 100 do // if possible lightGem.addValue(bush_density); // else if bush_density == 50 and nearest enemy is looking at bush enemy.raiseAlert end else if bush_density < 50 and nearest enemy is looking at bush enemy.canSee(player); end else player is totally hidden end end else if bush_density <= 0 or bush_density > 100 do error density should never be 0 or more than 100 // for example end end else do nothing and wait end endI'm sure the logic could be improved but this is what i can think of at the moment, hope it makes some sense and helps someone.
-
Like Springheel said the AI doesn't see trough alpha textures, even if the player would be obviously visible behind or inside a alpha tested object, for rustling sounds is just a matter of detecting if the player is touching the object, and then triggering a sound. There's plenty of ways you can do that, for example using a trigger on the editor, using a script with $entity.distanceTo($player1) or even with $entity.touches($player1), etc. This could be solved, if the AI vision was capable of per pixel testing instead of per-polygon, so they could discard invisible pixels from the vision calculations, but i'm sure this would be really really bad for performance. If some day someone does a game where the AI is calculated "in the cloud" instead of the client PC, using a neural-net then this would be perfectly possible. ;D
-
Fantastic! What kind of documentation i want? Something like: How do you plug a glsl shader into a material? Is it exactly like the ARB ones? For example in fhDoom calling GLSL shaders in materials is not exactly like the ARB way, is similar tho, for example: In ARB you do this: In GLSL you do something like: Other is, how is GLSL connected to the TDM engine? In ARB we have more or less this globals, took them from a Doom3 ARB shader How does that relate to GLSL? You or someone could also take a idtech ARB shader convert it into the GLSL version and explain all the steeps needed to do that. Btw i'm not asking for you or someone to teach how to convert ARB into GLSL per se, what i'm asking is more how the conections to the engine render and materials are between the ARB and the GLSL version.
-
I will try write glsl shaders if it ever gets implemented in TDM, but good documentation needs to be made by who implements a GLSL render, about how all of it is connected into the engine and how shaders are plugged into materials, etc. Btw is not #define just a C/C++ compiler/pre-processor keyword? At lest that was what i learned when learning programming.
-
Yes some of the effects in Sikkmod are very demanding but imo has more to do with the effects them self's or how they were written then the inability of the engine to render them at good performance, i'm sure you know ARB performance is dependent on the GPU more then anything. Vanilla idtech 4 is indeed old by today standards and relies a bit to much on the CPU side of things and is single-threaded, where modern engines are more GPU oriented and multi-threaded, it was just made at the time where CPU's (and single core ones) where more important than GPU's, apart from this obviously important limitations imo is a very advanced engine. Also you have a "heavilly modernized" version of idtech 4 on the BFG version, but i would be impressed if the TDM team would risk such a jump of engines.
-
The nice thing about the idtech 4 material editor is that it shows the ARB shader stages effects has well the materials animations using the keywords like scroll, translate etc, very handy imo, but not something you can't do some other way, no wonder the materialEditor is pretty much unknown. I'm learning programming (on my own) and even tho i don't consider my self a real programmer i found that it was a important skill to have as a game designer. Btw Modo supports .lwo natively, is the tool i use, it was made by ex lightwave engineers, Modo was also one of the tools used by id Software to make Doom 3 maps and afaik it does not support ASE. edit: NeonStyle terrain editing on DR will be a feature that will take a large amount of time to implement if ever, so the best you can do, is go to the next best thing, that is to use one of the free terrain editors on the internet and then prepare them for import into TDM using blender for example or learn how to model and paint terrain directly inside Blender, is not that hard. Just know that any large terrain made in a 3D tool needs to be cut into relative small sections, and assembled inside DR just like the Springheel modules, so idtech 4 doesn't render the all thing at once when a light strikes a small part of the terrain surface.
-
I think some of you guys underestimate the engine TDM is using, a Steep Parallax Mapping mod was made for original Doom 3 and that game uses ARB and OpenGL 1.5, Sikkmod also implemented on original Doom 3 plenty of advanced shaders, including, Bloom, SSAO, HDAO and others, Parallax Occlusion Mapping, HDR lighting, etc, etc, guys the engine is better then you think, sometimes we just need to give it a small push. Perhaps i'm recalling wrong but i seam to remember someone on this forum showing Parallax Occlusion Mapping working on TDM, just don't remember who or what thread. I never tried and i don't bet it will work but you could try to substitute the TDM interaction shader by one of the Doom 3 Sikkmod interactions shaders and see what it does, there is at lest one with POM, if it works you can test your bump maps with it, until someone implements POM natively into TDM.
-
lol yes sorry story of my life English not being my primary language, but you know what is also funny idtech 4 also has a material editor! Is not very intuitive but does the job, is not inside of DR but is better than nothing i suppose. Just type "materialEditor" on the console, be sure to run the game in window mode and disable AA. Like almost all vanilla idtech 4 tools is crash prone so save often, personally i use it mostly to preview materials when i'm on a hurry. Btw to navigate inside the material preview window do this: To move the light use the Right mouse button To move the view use the Left mouse button To Zoom the view near the preview box use the Left mouse button + alt To move the light near the box use Right mouse button + alt that is pretty much the extent of my knowledge on the materialEditor. ;D edit: Btw don't mess with the "text" window if opening a hand made material, i found the hard way that it will delete all your custum code!
-
Yes steep parallax mapping is a very nice technique and one of the most realistic around specially because it can do self shadowing on the bumps, the problem, is a very performance hungry technique, IMO POM (without self shadowing) looks awesome and is faster than steep Parallax Mapping. In the end IMO for a game like TDM where performance is critical, that PM with offset limiting seams the best option, today PM is considered to be almost as fast as normal mapping and it fakes geom better than it (when it works fine). Btw https://www.youtube.com/watch?v=gcAsJdo7dME I'm sure this kills performance more than x64 Tesselation but is impressive how much you can fake today with just texture tricks and cleaver math.
-
Hum, i don't agree, i saw nothing on that video that made me say, yes this is pretty much impossible in idtech 4, what the artist was doing imo was just vertex painting or texture blending, two things you can render in idtech 4 just fine, just not inside DR (you can place decals but that is technically different from what i'm saying). I know painting inside DR would be a fantastic thing to have, even tho I don't know how difficult it would be to implement, i assume is not a easy task, DR is also being worked by a single person, Greebo, on his free time, so unless some other blessed soul starts helping, i don't think this will happen anytime soon, IMO for the time being you guys can just export the surface you want to "paint" from DR has a obj, open that on blender/Modo/Maya and paint there, if you know how... Btw Judith, unless the TDM team removed it, idtech 4 has a GUI editor (from Quake 4) just type "editguis" on the console, just know this, it has the tendency to crash, so save often, and the gui preview inside the editor is not exactly how it will render ingame, specially if you put animations on it, is good for static GUI's tho. This is personal opinion but i think you really don't need a GUI editor if you are making GUI's, there's some console commands that imo make working on them a breeze. they are: testgui guipath (if you put this on a shortcut or .bat file, for example "name.exe +set r_fullscreen 0 +set r_multiSamples 0 +set r_gamma 1 +set r_mode 6 +set vid_restart +testgui /guis/name.gui") it will open the game in a window and immediately open the gui, then just use "reloadGuis" on the console to see all the changes you make to the gui code, in almost real time without the need to start the game again or reload a map. Another nice command is "gui_debug 1" this makes the bounding boxes of the various windowDef's visible (just like the gui editor) and also shows the mouse screen coordinates, good to know the screen coordinates to input into the windowDef's. Hope this was helpful.
-
That parallax mapping technique on the first link with offset limiting seams to solve the grazing angle problem pretty nicely! IMO one good bullet point to chose this PM tech over others, performance is all that matters if the visuals are good enough.
-
No problem and sorry if i came across has a douch, btw normal mapping can also technically be considered bump mapping, both just simulate "bumps" on a 2D surface, bump mapping using a B&W texture was the first tech invented to simulate "bumps" (another very old tech that i don't seam to remember the name now, also made that but made everything look like shiny glass from any angle), then normal mapping was invented, visually a bump map and a normal map do the exact same thing, the diference, is that the B&W bump map holds extra info that was not really needed to simulate simple bumps, it has the ability to hold complex height info about the surface in all three components, x y z (that is why it is still used today for Tessellation for example), making the math more heavy then it needed to be, a normal map works just by using the normal's of the surface, simplifying the math (there the term normal mapping) and only on the x y components and making z (height) always be 1, visually this made no diference but changed everything on the performance front, so yes, performance does play a major role in the choosing of what technique to implement, specially those that make heavy use of ray tracing, like Self Shadowing Parallax Occlusion Mapping, Relief Mapping, Steep Parallax Mapping, etc, etc, so imo referring to the techniques by their names prevent confusion and headaches in the long run. Also IMO both Parallax Mapping and Parallax Occlusion Mapping could be implemented, used perhaps has different LOD stages or different game quality stages, they can be coded to work with the same bump map, but one works on older PC's and is faster, but looks worse (at grazing angles), the other looks better but is slower and only run on "modern" shader model 3.0 GPU's and beyond. Yes but afaik is just storing a flat height of 1 and most of the time the z-component is not even needed to do correct normal mapping, there the blue channel not being even used in some games, so, from what i know, a simple normal map, do not stores enough info to make a good B&W bump map (also called height map), but some do try to do it with varied success, i just don't know exactly how they do it, would love to know tho.
-
Ha ok my bad, about using only the normal map for POM (or even PM) IMO the only way i see, is putting the bump map on the alpha channel or somehow improve the info on the blue channel, if someone is claiming they can make good parallax info from a "normal" normal map, and only use the green and red channel like most normal maps are, i also want to know how they do it. lol yes there's plenty of (virtual displacement mapping techniques), btw the "Two Worlds 2" guys, claim its faster than POM but i don't know of any other game where that technique is implemented, and i never played that game to know if is true, perhaps some patent problems are preventing it from spreading?
-
https://www.gamedev.net/resources/_/technical/graphics-programming-and-theory/a-closer-look-at-parallax-occlusion-mapping-r3262
-
MirceaKitsune please don't take this wrong but can you be more specific, what kind of Parallax Mapping are you referring to? From your comments and reference to fhDoom I think you are speaking of POM (Parallax Occlusion Mapping) but removing the Occlusion part from the name, so confusing me, it may seam like is just a different name for the same thing but is not, they are different things, not only on visuals but also on performance, where PM (like i said a older tech) runs as fast as normal mapping today, POM (a modern evolution of PM) is much slower, from my experience slower than real tessellation! (GPU's are faster at rendering triangles than pixels), second where PM viewed at grassing angles looks really bad imo, looks like molten glass, POM looks fine (if using a good bump map) viewed from any angle, the only diference in visuals of POM from Dx11 Tessellation, is that it doesn't change the silhouette of objects wheres real Tessellation does. Example of PM from Fear http://www.ixbt.com/video2/images/tech_fear/fear_pm_03.jpg bad PM viewed from extreme grassing angle http://www.gatheryourparty.com/wp-content/uploads/2013/02/2013-01-05_00014.jpg POM viewed from grassing angle https://i.ytimg.com/vi/bfS4J65fXJY/maxresdefault.jpg Very nice imo example of POM https://forums.unrealengine.com/attachment.php?attachmentid=14135&d=1413290592 About POM against Tesselation (Displacement mapping) http://www.d3dcoder.net/Images/Samples/ParallaxDemo.jpg PS. Sorry if i look like i'm "showing off" my knowledge or something but graphics tech was always a subject that fascinated me.
-
That is not totally true, specially for techniques like POM, some engines do use a single normal map for everything but what they do is, one, they put the bump map on the alpha channel of the other textures (diffuse or specular) or the normal map it self, two, they put extra height info in the blue channel of the normal map, normally the blue channel has a small amount of height info, or no info at all, is just full white ( that is how the blue channel is represented in photohop, could look different on other tools), if i'm remembering correctly idtech 4 normal maps have a full white blue channel, meaning they have no usable height info on the blue channel, you can see if this is true by looking at a vanilla Doom 3 normal map in photoshop for example, other times, you can see right away that the normal map has extra info, because it looks strange not like a "normal" normal map should look, for example Penumbra Overture has some normal maps with obvious extra info they look different from the rest. POM is disabled by default in fhdoom and i'm sure is because Doom 3 lacks good height info on its normal maps alone but i do recall some old shader mods for Doom 3 were POM like tech was used (steep parallax mapping i think it was) and they converted the normal maps some how and the tech looked good enough. btw this is a nice read: https://www.katsbits.com/tutorials/textures/understanding-oblivions-parallax-maps.php
-
I know that engine is the most modern but also more similar to the original one, it has full support for all vanilla idtech 4 features and tools, for example the vanilla GUI system, where all engines based on Doom 3 BFG source require Flash, at lest for fullscreen GUI's. There's other stuff on it that is cool has well imo, support for Qt GUI based tools, for example the fhDoom engine light editor is made with it, and looks very nice imo, unfortunately is the only converted tool for now plus i don't know if you can do game based GUI's with it. It also has direct support for GLSL shaders, their usage in materials is very similar to the ARB ones. Btw MirceaKitsune is just a technicality, but fhDoom has support for Parallax Occlusion Mapping or POM (off by default), that is a different tech from Parallax Mapping, that is a older and imo uglier technique (makes everything look like molten glass), POM is similar to Horizon Mapping for example. Also vanilla Doom 3 has support for POM as well but you need to install a modified ARB interaction shader, if i'm not mistaken SIKKmod has one, POM also requires a bump map (black and white texture) in the case of fhDoom that bump map most be put onto the alpha channel of the specular map, btw not confuse with the bump keyword for TDM materials that only convertes a bump map into a normal map.
-
I can't agree with this, IMO because of GOG many new gamers can play old games without the need for crazy fixes on their part or the need to be computer savy, because of GOG the original developers (or publishers) can still make some money on their old games, GOG helped developers knew how comercial viable their old IP's or genres of games still were, IMO that also helped fuel the kickstarter wave of remakes of old games like System Shock and others, because of GOG DRM is not thought to be has necessary has it once was and showed PC gamers weren't all just "pirates", because of GOG old IP's are returning, if not they would be pretty much dead, only to be experienced by a small nich of hardcore fans, many games even ones very old were never abandonware, in the sense that anyone could take the IP and do with it what they wanted, the IP owners add all rights over them and so no one wanted to mess with that mine field, that caused many games IP's to just be dead period and fans were losing hope of ever seeing a follow up to them, now they have new hope. And lastly GOG never killed the mod scene, anyone can still make mods for their old favorite games and know they will probably be experienced by new people.
-
You are totally right but imo you are forgetting a important fact, TDM engine uses stencil shadows, the more polys you give a model the heavier it becomes to calculate the shadows, if you don't want to be forced to make a shadow mesh for all modules, is best to be careful with polys, is all a balancing act but i recommend anyone making models for TDM to do this, for unique models use the necessary poly's to preserve the shape and make it look good, if necessary make a shadow mesh, for modules that will be cloned many many times, like walls and have the potencial to be rendered also many times on a single scene or frame, save on the poly's, use normal maps the most you can. Btw even tho afaik no one uses POM (parallax occlusion mapping) on TDM, tho i think the engine interaction shader supports it, is always better to use real geometry because GPU's are faster at rendering triangles than they are at rendering pixels (shaders), specially ray traced pixels.
-
That function should do the trick indeed, is something i never found on vanilla idtech 4 script, from a code search i did now it seams On() and Off() light functions from vanilla idtech 4 work by changing the light level/color not if it is hidden or not.
-
I know that on vanilla doom 3 you can turn on and off a light with : $light_name.On(); or $light_name.Off(); But in this case i don't know how to detect the state of the light But i know that you can ask if a entity is hidden or not, using the function: $entityName.isHidden(); So i would recommend using $light_name.hide(); or $light_name.show(); To turn a light on or off. In this case you can just do it like so; if ( $light_name.isHidden() == TRUE ) // the object is hidden { dostuff } else if ( $light_name.isHidden() == FALSE ) // object is not hidden { dostuff } else { do other stuff } // this is opcional
-
Don't know if is the right place for this but was trying to find links about terrain techniques for games and found this links, could be useful to any TDM idtech4 coding guru when trying to implement a terrain system some day, btw before anyone thinks, no i'm not implementing terrain in any game or engine, just curious about this stuff. http://www.vertexasylum.com/downloads/cdlod/cdlod_latest.pdf http://vertexasylum.com/2010/07/11/oh-no-another-terrain-rendering-paper/ http://frictionalgames.blogspot.pt/2010/11/tech-feature-terrain-geometry.html
