Jump to content
The Dark Mod Forums

Announcement: SEED system


Tels

Recommended Posts

I am not so sure, haven't read the articles yet. But from the looking into the internal datastructures, and what I remember, the CMs look like "plane + distance from origin" to me. Scaling such a model is complicated, because just moving the plane further away is not correct.

To be honest, don't understand the problem...

 

If you want to scale it by constant factor C isotropically then you can multiply everything with coordinate and scale sense by C and do nothing with things like normals. To my mind it should work correct.

 

The anisotropic scale is a bit worse. If you scale each vector (x,y,z) by factor (Cx, Cy, Cz), then each normal (Nx, Ny, Nz) should transform into (Nx/Cx, Ny/Cy, Nz/Cz). If there is a plane, then its normal is transformed as stated and its distance is not changed. Just remember to change it when you renormalize the normal (it does not have unit length no more).

 

In general case: there is a plane with equation in homogenous coordinates in form (Nx, Ny, Nz, d) dot (x, y, z, 1) = 0. You want to transform the world by multiplying it on the 4x4 matrix A. It is well known from shader programming (applying modelview transformation to normals) that the "plane vector" must be multiplied by inverse of transpose of A. So the new plane parameters are (A^{-1})^T * (Nx, Ny, Nz, d). The correctness can be checked by noticing that dot product of transformed plane vector on transformed point vector remains the same. Notice that combined rotation, translation and arbitrary scaling are included in this case.

I hope that I'm not mistaken about the formulas above :laugh: If you find a way to change all the coordinate parameters, then the formulas how to change them are indeed obtainable.

Link to comment
Share on other sites

To be honest, don't understand the problem...

 

If you want to scale it by constant factor C isotropically then you can multiply everything with coordinate and scale sense by C and do nothing with things like normals. To my mind it should work correct.

 

The anisotropic scale is a bit worse. If you scale each vector (x,y,z) by factor (Cx, Cy, Cz), then each normal (Nx, Ny, Nz) should transform into (Nx/Cx, Ny/Cy, Nz/Cz). If there is a plane, then its normal is transformed as stated and its distance is not changed. Just remember to change it when you renormalize the normal (it does not have unit length no more).

 

In general case: there is a plane with equation in homogenous coordinates in form (Nx, Ny, Nz, d) dot (x, y, z, 1) = 0. You want to transform the world by multiplying it on the 4x4 matrix A. It is well known from shader programming (applying modelview transformation to normals) that the "plane vector" must be multiplied by inverse of transpose of A. So the new plane parameters are (A^{-1})^T * (Nx, Ny, Nz, d). The correctness can be checked by noticing that dot product of transformed plane vector on transformed point vector remains the same. Notice that combined rotation, translation and arbitrary scaling are included in this case.

I hope that I'm not mistaken about the formulas above :laugh: If you find a way to change all the coordinate parameters, then the formulas how to change them are indeed obtainable.

 

Here is the code for Rotation/Translation:

 

idTraceModel::Translate
============
*/
void idTraceModel::Translate( const idVec3 &translation ) {
       int i;

       for ( i = 0; i < numVerts; i++ ) {
               verts[i] += translation;
       }
       for ( i = 0; i < numPolys; i++ ) {
               polys[i].dist += polys[i].normal * translation;
               polys[i].bounds[0] += translation;
               polys[i].bounds[1] += translation;
       }
       offset += translation;
       bounds[0] += translation;
       bounds[1] += translation;
}

/*
============
idTraceModel::Rotate
============
*/
void idTraceModel::Rotate( const idMat3 &rotation ) {
       int i, j, edgeNum;

       for ( i = 0; i < numVerts; i++ ) {
               verts[i] *= rotation;
       }

       bounds.Clear();
       for ( i = 0; i < numPolys; i++ ) {
               polys[i].normal *= rotation;
               polys[i].bounds.Clear();
               edgeNum = 0;
               for ( j = 0; j < polys[i].numEdges; j++ ) {
                       edgeNum = polys[i].edges[j];
                       polys[i].bounds.AddPoint( verts[edges[abs(edgeNum)].v[iNTSIGNBITSET(edgeNum)]] );
               }
               polys[i].dist = polys[i].normal * verts[edges[abs(edgeNum)].v[iNTSIGNBITSET(edgeNum)]];
               bounds += polys[i].bounds;
       }

       GenerateEdgeNormals();
}

 

Now for Scale? :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Here is something scary: I did set the plantmodels to "nonsolid", but didn't think that that would remove their clipmodels and thus their size would end up with "0x0" units. But the density algorithm uses the size to make a floorplan, e.g. how many entities should it plant. It did catch the 0x0 case, but used 0.1x0.1 instead, which is still quite tiny.

 

So it planned that a lot of entities will fit. Really lots of entities. Huge amounts of entities. So many, that the map never loaded, despite me correcting the default density downward until I reached something like 0.0001 (compared to 1.0!). And still, the system planned a lot of entities - but this time it took about 4 minutes (243 seconds according to D3) loading time, and 1.9 Gbyte of memory and then it was done. Whew. With an average FPS of about 1 (and second-long stutters if you moved) one would see this:

 

post-144-12948662149_thumb.jpg

post-144-129486649211_thumb.jpg

 

This, ladies and gentlement, is a tightly-packed boletus farm, sporting 397774 models that were combined into 26 rendermodels (aka "true entities"). The cattails in the background aren't a few, either, this are about 30000 models...

 

I wasn't patient enough to move closer (stuttering due to model rebuilds ranged between 2 and 10 seconds), but the spyglas shows the massive amount of tris, plus some black boxes for the cattails (seems something overflowed somewhere Edit: This was a typo in the entity def and has been corrected since. The people responsible for the typo have been sacked.):

 

post-144-129486644954_thumb.jpg

 

 

All in all a quick estimate gave me about 2 million models in that map (give or take a few hundred thousands..). Astonishingly enough, the game did run well enough for me to make screenshots :)

 

views:4 draws:235 tris:12782603 (shdw:306) (vbo:0) image: 49.9 MB

 

Of course, I need to add some safeguards to avoid this mess in the future - plus, 4 minutes to generate these entities is way too long. ;)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Sorry, forgot to renormalize normal in Rotate... Here is the new version.

 

Cool.

 

By the way, is there any simple way to check correctness of this code?

 

I can add the code, and run a quick test with scaling a rendermodel+clipmodel, and see if it looks correct in the game. Will post the results here.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Haven't had time today for the clipmodel change, but I am eager to try it out. If that works, it is the biggest thing ever!

 

Anyway, worked on the code:

 

* the LODE can use image maps, but their support was only very primitive, so I improved it:

 

** image maps can now use scaling: "scale_map" on the LODE as default, or "lode_scale_map" on the target entities, as well as "lode_scale_map_x" and "lode_scale_map_y" for each axis, with default "scale_map_x" and "scale_map_y". Will document this later on the wiki.

** Likewise, "lode_map_ofs_x" is also possible (0..1.0)

 

This means you can now re-use the same image map image and scale/shift it around to select different parts on it.

 

** Image maps are now also by default searched in textures/lode, the code now tries automatically ".png", ".tga" and as fallback ".jpg" and also renamed the map from "lode_sinus.tga" to "sinus.png" (Thanx to greebo!). The upshow of all this is that you now can write

 

"lode_map" "sinus"

 

on an entity, and it works. Much easier to type and remember.

 

* I also fixed the code to enforce a minimum size for entities (because non-solid entities were set to 0 size), this helps the planner to get a grasp on the default density. However, the size of an entity is all that should play a role in density, because a small flower might be way more seldom than a bigger grass bush. So I added "lode_base_density" which is multiplied by the density and defaults to "1.0". Our entities contain these values already.

 

Mappers don't need to set it, but our default LOD/nature entities contain this value so that their density apears to be "right". Mappers can thus tweak the "density" value starting with 1.0 - instead of having to know what the baseline density for this entity is.

 

* the black boxes for some cattails above where a typo in the low model for cattails2. Fixed this.

 

* also had an idea how to prevent the "too-low-resolution-imagemap shows pixel borders when used with lots of entities on a large area" in an easy way (read: it won't make things slower). But more on this tomorrow.

 

Here is a screenshot, showing the same entity used with the same image map, but different scaling/offsets. The image doesn't really show it (should have used the same random seed for all), but I'll make a better screenshot for the wiki.

 

post-144-129495833536_thumb.jpg

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Make a testcase at the boundaries of each argument range and 0.
I meant simple way...

I tried to check all this stuff with a chair floating in the bath :rolleyes: That was almost useless. Though the assert must be separated from calculations indeed. I think it's better to wait until Tels checks it.

now y'all have 2 great new codefolk?

Not sure about it :blush: I'm very happy to help the TDM project (and since mapping/modelling/etc doesn't sound good to me, coding is the only help I can offer). But I already have bunch of hobbies, both programming related and not. That's why I'm not sure that I'll be here on forums for long :( For example I haven't run TDM for a year before now. So I'll better remain in shadows. But if there are not urgent coding tasks (especially which do not require understanding and treating a lot of TDM code), I'll gladly try to handle them! Just don't want to disappoint anyone who counts on me.

 

By the way, a few questions about LODE possibilities: if LODE places objects with clipmodels, is it guaranteed that they do not intersect? Is it possible to place objects on a complex terrain (not just plane)? And finally: can LODE generate the terrain itself?

tracemodel.cpp.txt

Edited by stgatilov
Link to comment
Share on other sites

I meant simple way...

I tried to check all this stuff with a chair floating in the bath :rolleyes: That was almost useless. Though the assert must be separated from calculations indeed. I think it's better to wait until Tels checks it.

 

I needed to add a Scale() method to clip.h, and one to physics_staticmulti.cpp and also then use it in my LODE code. Unfortunately, it was *very* late yesterday and it crashed, will see what I can do today.

 

Edit: Btw, it would be easier if you could send diffs produced with "diff -u". Also, the latest code you posted, what is the difference to the previous versions?

 

Not sure about it :blush: I'm very happy to help the TDM project (and since mapping/modelling/etc doesn't sound good to me, coding is the only help I can offer). But I already have bunch of hobbies, both programming related and not. That's why I'm not sure that I'll be here on forums for long :( For example I haven't run TDM for a year before now. So I'll better remain in shadows. But if there are not urgent coding tasks (especially which do not require understanding and treating a lot of TDM code), I'll gladly try to handle them! Just don't want to disappoint anyone who counts on me.

 

We could certainly need help, esp. from talented people as you. http://bugs.angua.at/my_view_page.php we have over 300 open bugs, and I am sure a lot of them are small things that can be done in isolation.

 

By the way, a few questions about LODE possibilities: if LODE places objects with clipmodels, is it guaranteed that they do not intersect?

 

No, intersection between models placed by the LODE is not yet implemented. They do not intersect whatever was there before, but between themselves, they do not check.

 

(It should technically be the case that if one LODE places entities, they exist before the next LODE places his entities, so they would test for intersection. But during the phase of constructing the entities, these do not really yet exist.)

 

Is it possible to place objects on a complex terrain (not just plane)?

 

Yes, no problem. It can work on hills/whatever, and even take into account the height, so it does place less entities depending on terrain height. http://wiki.thedarkmod.com/index.php?title=LODE_-_Spawnargs#floor

 

The only limit is that the "placement direction" aka "gravity vector" is always pointing down. That should be changed so you can place things on a wall, or on the ceiling, or even in a "explosion" fashion all around,but I haven't had time to look into this.

 

And finally: can LODE generate the terrain itself?

 

No, this is one of my long-term projects, but not that easy because "how do the mappers specify how the terrain should look" question? But not having to manually generate patches for terrain would be cool.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Edit: Btw, it would be easier if you could send diffs produced with "diff -u". Also, the latest code you posted, what is the difference to the previous versions?

 

The matrix inversion is moved out of assert(). I often forget that release builds wipe the code inside assert out.

 

Send unified diffs file-by-file? Well, it sounds good for small fixes. I store TDM source inside mercurial. I tried to send to greebo the whole directory patch for savegame compression produced by mercurial but some program (I guess tortoiseSVN?) didn't swallow it. By the way, there is no such concept as "patch" in SVN.

 

The easiest solution would be to open public read-only SVN access: then everybody would be able to send proper patches. And moreover, everybody would be able to play TDM with the latest SVN build. But greebo said that SVN is not yet ready for such shock. And anticipation for major updates like 1.04 would be less then :laugh:

http://bugs.angua.at/my_view_page.php we have over 300 open bugs

OK. It sounds like endless source of inspiration! :laugh:

Link to comment
Share on other sites

The matrix inversion is moved out of assert(). I often forget that release builds wipe the code inside assert out.

 

Thanx, I'll use the latest version then. Was busy fixing the LOD bug in v1.03 the entire morning and only found time now to loo into this.

 

Send unified diffs file-by-file? Well, it sounds good for small fixes.

 

You can also send a unified diff for all files together. The diff has the advantage that I can apply it to my SVN directly, instead of making a diff from yours and the original, then apply that diff to my current version.

 

I store TDM source inside mercurial. I tried to send to greebo the whole directory patch for savegame compression produced by mercurial but some program (I guess tortoiseSVN?) didn't swallow it.

 

I think we should give you access to SVN fast, because you do good work and are hampered by not having access. Can you please PM sparhawk with your wanted username/password combo, he can set you up. I'll talk to the team, but I don't think they wouldn't want you to be on board :)

 

Public SVN access will only come when our new server is online, but the new hoster seems to have problems with the hardware.

 

By the way, there is no such concept as "patch" in SVN.

 

Well, I had to make a diff and use "patch -p0 <patch.txt" to apply it, so I am still refering to the "diff" as "patch". Old habits die hard :)

 

The easiest solution would be to open public read-only SVN access: then everybody would be able to send proper patches. And moreover, everybody would be able to play TDM with the latest SVN build. But greebo said that SVN is not yet ready for such shock. And anticipation for major updates like 1.04 would be less then :laugh:

 

True :) Also it can get pretty distracting when the public follows you to close, we for instance get this already when people follow the bugtracker comments, but don't quite understand them, and then post ramblings on the forum :)

 

OK. It sounds like endless source of inspiration! :laugh:

 

Yeah :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

About scaling of clipmodels:

 

ID_INLINE void idClipModel::Scale( const idVec3 &scale ) {
       if( IsTraceModel() )
       {
               // copy & scale the tracemodel
               // Tels: Is the copy nec.?
               idTraceModel trm = *(idClipModel::GetCachedTraceModel( traceModelIndex ));
               trm.Scale( scale );

               LoadModel( trm );
       }
}

 

The code above added to clip.h doesn't do anything, I guess because the clipmodel I used was construced with LoadModel(name) which is:

 

bool idClipModel::LoadModel( const char *name ) {
       renderModelHandle = -1;
       if ( traceModelIndex != -1 ) {
               FreeTraceModel( traceModelIndex );
               traceModelIndex = -1;
       }
       collisionModelHandle = collisionModelManager->LoadModel( name, false );
       if ( collisionModelHandle ) {
               collisionModelManager->GetModelBounds( collisionModelHandle, bounds );
               collisionModelManager->GetModelContents( collisionModelHandle, contents );
               return true;
       } else {
               bounds.Zero();
               return false;
       }
}

 

I am not sure if we can access the contents of the loaded model from collisionModelManager. Need to go shopping now, but will look into this later, but probably only tomorrow as the evening is planned already :/

 

(all this tracemodel/clip/clipmodel stuff makes my head spin - so many layers of indirection...)

 

Edit: Possible way (cm/collisionmodel.h):

 

       // Sets up a trace model for collision with other trace models.
       virtual cmHandle_t              SetupTrmModel( const idTraceModel &trm, const idMaterial *material ) = 0;
       // Creates a trace model from a collision model, returns true if succesfull.
       virtual bool                    TrmFromModel( const char *modelName, idTraceModel &trm ) = 0;

 

* 1. Get the tracemodel (if (TrmFromModel( "modelname here", trm) == ..)

* 2. Scale the tracemodel (trm->Scale())

* 3. Re-insert (SetupTrmModel(trm material))

* 4. ???

* 5. Profit!

 

If we replace "LoadModel().." with the above, it might work.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

* 1. Get the tracemodel (if (TrmFromModel( "modelname here", trm) == ..)

* 2. Scale the tracemodel (trm->Scale())

* 3. Re-insert (SetupTrmModel(trm material))

* 4. ???

* 5. Profit!

 

Not sure that it will work. When you reinsert the scaled model back it will likely create new collision model inside engine and return its handle to you. And what are you going to do with that integer number? :mellow:

 

As far as I understand this clip/trace/collision-model mess, things work this way:

 

 

idTraceModel is just a polyhedral data. It is loaded into Doom 3 physics engine. And I suppose it is copied into Doom3 on loading and probably preprocessed.

cmHandle_t is a handle to internal tracemodel object inside Doom3. It is the copy I spoke about, I suppose... Since we cannot access it in direct way, ID provided us with this magic handle that we can pass to some routines to do some cool things :laugh:

 

idClipModel looks like atomic piece of physical substance of entity. It has materials, own orientations and origin and stuff like that. Though I don't understand how these origin and orientation parameters are used. It is a bad idea to add Scale function to it because all functions like Translate and Rotate do not change the polygonal data (which is tracemodel) right now while your Scale indeed tries to change it. This object stores a handle to tracemodel (cmHandle_t).

 

 

idClip - don't know what it is. Except that its Motion routine is called from rigidbody source and is redirected to the collision model manager.

idPhysics coordinates all the object physics at the highest level. It stores a list of clipmodels.

 

So if you need to change tracemodel of each entity individually, you can do something like the following. Go through links idEntity->idPhysics->idClipModel. Then get its collision model handle. Then ask that collision model manager to extract the polygonal data (idTraceModel) for you, then do whatever you want with it, then load it back to manager. And finally set the received cmHandle_t back to tracemodel.

 

 

But this way number of tracemodels will increase with every new scaled entity. Not sure that it is a proper way. But it is unavoidable because the code for collision is closed and it can collide models with rotation+translation but cannot collide anything with scaling.

Link to comment
Share on other sites

Interesting, if these methods for scaling work, could this be used for scaling single models via an entity key-value ?

 

Currently you have to scale models outside of the game ( not counting the rotation matrix "hack" that doesn't work properly ) - this could be a really useful side-product of LODE development :).

Link to comment
Share on other sites

Interesting, if these methods for scaling work, could this be used for scaling single models via an entity key-value ?

 

Currently you have to scale models outside of the game ( not counting the rotation matrix "hack" that doesn't work properly ) - this could be a really useful side-product of LODE development :).

Well, theoretically per-entity scaling is the thing Tels is trying to implement now.

 

But the current state of scaling is: You want to scale idTraceModel? No problem (though the code is not checked yet). Pure linear algebra exercise :laugh: But Doom3 engine is not suited for colliding scaled models. And I feel that it will cause A LOT of trouble and a lot of work to understand how to push scaled models into it.

 

 

 

 

 

Link to comment
Share on other sites

The easiest solution would be to open public read-only SVN access: then everybody would be able to send proper patches. And moreover, everybody would be able to play TDM with the latest SVN build. But greebo said that SVN is not yet ready for such shock. And anticipation for major updates like 1.04 would be less then :laugh:

 

Ironically this is going to lead me to another trying-to-be-restrained-but-oh-so-anxious nudging...

 

Holy-moley. This would be great. I would then be required to learn how to compile and link with modern IDEs; long-over-due and probably not as miserable as I imagine...???

 

AND

 

I wouldn't be (quite) ~so~ annoying as far as things like this very post here in are-we-there-yetting.

Link to comment
Share on other sites

Not sure that it will work. When you reinsert the scaled model back it will likely create new collision model inside engine and return its handle to you. And what are you going to do with that integer number? :mellow:

 

As far as I understand this clip/trace/collision-model mess, things work this way:

 

 

idTraceModel is just a polyhedral data. It is loaded into Doom 3 physics engine. And I suppose it is copied into Doom3 on loading and probably preprocessed.

cmHandle_t is a handle to internal tracemodel object inside Doom3. It is the copy I spoke about, I suppose... Since we cannot access it in direct way, ID provided us with this magic handle that we can pass to some routines to do some cool things :laugh:

 

idClipModel looks like atomic piece of physical substance of entity. It has materials, own orientations and origin and stuff like that. Though I don't understand how these origin and orientation parameters are used. It is a bad idea to add Scale function to it because all functions like Translate and Rotate do not change the polygonal data (which is tracemodel) right now while your Scale indeed tries to change it. This object stores a handle to tracemodel (cmHandle_t).

 

 

idClip - don't know what it is. Except that its Motion routine is called from rigidbody source and is redirected to the collision model manager.

idPhysics coordinates all the object physics at the highest level. It stores a list of clipmodels.

 

So if you need to change tracemodel of each entity individually, you can do something like the following. Go through links idEntity->idPhysics->idClipModel. Then get its collision model handle. Then ask that collision model manager to extract the polygonal data (idTraceModel) for you, then do whatever you want with it, then load it back to manager. And finally set the received cmHandle_t back to tracemodel.

 

 

But this way number of tracemodels will increase with every new scaled entity. Not sure that it is a proper way. But it is unavoidable because the code for collision is closed and it can collide models with rotation+translation but cannot collide anything with scaling.

 

Thanx for the explanations, I'll read this later and experiment with it. As far as the "each scaled copy needs more memory" thing goes, I am pretty sure "each translated clipmodel ends up as a copy, anyway", or in other words, it should not use more or less memory.

 

In any case, you are right, an engine that does not copy individual clipmodels just because they are translated, rotated, or scaled would be much better - after all, you can check collision with the bounding box, and if that hits, just do the translation, rotation and scaling of the original data prior to check what you hit - that might be a tad slower, but it would save a lot of memory.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Just had a though. Tels, could LODE be used for the following task?

 

Some TDM players have complained that the maps look too clean. This is due to clean looking textures. Scenes CAN be dirtied up by manually placing func_static decal patches, which add a decal dirt texture on the selected surface.

 

The downside of this is that it is huge amount of work by placing the patches manually and every single surface must be decalled, otherwise any clean surface will shine it's cleannes compared to it's dirty neighbour.

 

LODE is basically a system which spawns cleverly models into the game.

 

Could it be possible to have a special lode_dirt-factinizer? A brush is turned into this lode entity. Then when the game starts, each and every brush surfaces which are inside this special entity get a basic grime decal applied on it.

 

If this could work, it would mean that to dirty up a scene, the mapper would only need to place this dirt-applier entity and when the map starts func_static grime-decals magically appear saving insane amount of mapper trouble.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Sotha, I have already fantasized[0] about a decal-spawner. The technical difficulties here are:

 

* spawn decals perpendicular to the surfaces (and fin dout which surfaces exist). I think the engine already has a "spray decal onto world", so maybe this could be used

* spawn decals only *once* per surface. It is a lot easier to spawn decals randomly and "spray" them around, but automatic dirtying of surfaces sounds complicated to me to get it 100% right.

 

Doable, but I have no clear idea how atm. What it could do are scenarios like "spray some leaf decals on the floor" or "sprays some dirt spots onto surfaces".

 

 

0: Steamy, hot wild fantasies involving lots of dark and dirty... surfaces..er I got carried away here.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If you are just making a scene look dirty, random decal placement would usually be fine (excluding the desire for custom hand-crafted weathered textures :wub: ) but usually grimes also serve to fake AO.

 

If you could have Dark Radiant search a map for recessed areas an mark them for increased decal density for SEED then that would be the time saver decal maniacs are looking for (this would also match the artistic intuition that dirt gathers in corners and crevices). Perhaps Rebb's old Quake AO algorithm could be plugged into Dark Radiant?

 

Edit:

 

With the current LODE system you could

 

1) Find a wall with recessed edges

2) select it with LODE for random decal generation

3) set a "power" inhibitor so that the decals only render at the edges

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Not sure about it :blush: I'm very happy to help the TDM project (and since mapping/modelling/etc doesn't sound good to me, coding is the only help I can offer). But I already have bunch of hobbies, both programming related and not. That's why I'm not sure that I'll be here on forums for long :( For example I haven't run TDM for a year before now. So I'll better remain in shadows. But if there are not urgent coding tasks (especially which do not require understanding and treating a lot of TDM code), I'll gladly try to handle them! Just don't want to disappoint anyone who counts on me.

 

Looks to me like you've been a great help in at least two very interesting and possibly very impacting areas so far: this and the savegame compression/reduction thing. I certainly can't complain; and I've got my popcorn out with a few of the others too -- enjoying the brainstorming. And glad to see that the TDM coders themselves are appearing to enjoy the fresh camaraderie.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...