PinkDot
-
Posts
1171 -
Joined
-
Last visited
Posts posted by PinkDot
-
-
Sweet, it would be nice to have a test map showcasing this model, so that those of us who are mapping-challenged can get a chance to run around in it.
I'm working on that!
From what I remember looking at the idPhysics_Player::StepUp code, the angles shouldn't matter. If the vertical step is low enough, it's supposed to just do a test where it moves the clipmodel up and over, and allow the step up if it fits. As you can tell by all the italics, I belive you that this isn't happening in reality. Maybe there is a bug in Id's stepping code that we'll have to find.After some modification of the side's angle I got a stage, where I couldn't walk on the grating but I could run onto it, so it looks like it's speed dependent.
Anyway - this part of the ship will probably change, cause I'm going to carve a hole there, make grating a door, so it might act properly when grating is entity or I can flush it with the deck if it still causes problems.
-
I guess after the moustache-awareness, we now need to implement an eye-patch
We don't have to implement that - what you see (in every game) is already one-eye view...
-
Thanks angua - I changed the angle of sides of that grating and that helped. I'm not entirely happy with its shape now, but that will do for now.
Ideally I'd like player to be able to overcome such small obstacles with no problem. It shouldn't depend only on the angle, cause we might end up with player unable to go onto a carpet...
Hmm.... but there must be something else wrong... stairs are usually vertical and higher than that gratinga and player can walk onto them...
---
BTW: and stairs problem is fixed now as well. It was actually my fault...
I didn't do dmap after reloading model... -
I'm having hard time with some small adjustments exporting that model in game. At this moment it's one model but eventually it will be divided into props. But anyway - player has problems with walking onto some surfaces.
He can't walk onto this one: (I lowered it down already and made sides at angles but didn't help)
Next - stairs - player walks onto stairs with no problem but can't walk onto deck from stairs. This is the only exception:
But he can't walk from stairs onto deck (when going upway, of course) in this situation in 90% of cases:
and never in this case:
I made stairs solid and flushed with deck but no change...
I have tried diffrent things - moving stairs, flushing with deck floor etc...
Of course jumping helps but that's not what I want...
Any ideas? These heights seem to me too small to be a problem. What else is taken into account when computing player's collision under feet?
-
yes, they can be used either on brushes or models. It'll be easy to make some simple buildings to put behind the wall - border of the map to create large city illusion.
BTW, windows are grid alligned, so you can split the brush exactly at the window borders and make them hollow or just change with any other window texture.
-
Recenlty I've been working on some architectural textures. Starting with halftimber style, as this is most TDM-ish and suits to my docks sea-port environment. This is a sample:
There are four textures so far. They're 1024x512, except for the gable texture which is 1024x1024 but eventually it will contain two diffrent gable textures (each of them using half space of texture).
I'm planning to go through more diffrent architectural styles: gothic, romanesque, victorian and others, so building a large cities won't be that difficult and life-long.
-
And wouldn't it be strange if a bright light shines directly onto the cloth, and all the wrinkles still appear?
maybe it would, but less strange
-
That's interesting, because it contradicts most of what I've been told about making textures for D3 (though instinctively I've been doing more what you suggest). Doesn't that make the texture look 'wrong' if the light is from certain angles though?
Well, you shouldn't paint on the texture strong lights and shadows - only smooth shadowing in concave parts. Basically - in game art you have to put into texture everything that is not computed in realtime. In old engines, textures contained lights and shadows and even highlights or some reflections. Now normal maps, specular maps and reflection shaders take care of it. But as game engines don't compute global illumination yet, it has to be painted. But it's all about feeling the right balance - not too strong and not too faint.
F.e. You wouldn't get folds on a shirt or curtain, cause they're only light and shadow, unless direct light cast onto it revealing bumps thanks to normal map. Wouldn't it look strange if completely even surface appeared to be strongly waved after lighting it up?
-
What is a 'color texture'?
As the name says - just pure colour (color?), without diffuse light nor specular. Not really good for game engines nowadays yet, as they compute only direct light, so it will look very flat in shadows.
As bumps and highlights are computed in real time, diffuse texture for engines such as doomengine should contain colour plus some diffuse light (such as skylight or global illumination).
hope it's clear but it doesn't harm to illustrate it:
colour texture:
diffuse texture:
-
Usually the diffuse does not contain light and shadow, as this would look wrong under different lights
Diffuse texture, as opposed to Color texture should contain some subtle diffuse light shadowing. Otherwise it looks flat, especially in ambient light only (no direct light). It shouldn't be too strong though, so direct light computed in game still would be stronger.
Looking at your texture - you're on the good way, I think. But if you want to be realistic, that shadow should follow the shape on shingles - now it's still flat
I know - it means a bit more work to do... 
-
Certainly, you can save a lot of polys with proper texture. And you can go even farther and bake some ambient light soft shadows between wooden beams and shingles - that gives much more depth and nicer effect and makes texture looks interesting even when in shadow.
-
sleepy is great, but could have some movement on the lower part of body as well.
-
As I remember they're from Thief 1.Actually, those are pretty much the same creatures as in Thief 1
That doesn't explain why they would go into The Dark Mod, since we're NOT copying Thief!
Here I got you! TDM is more realistic, as far as I can see, with only few exceptions.And BTW, I never played T1... (maybe except of half of 1st mission, or 2nd if you count training). I'm not fond of creatures and monsters in general - that was always keeping me away from that game.
-
yes, that texture has good normals and not noticeable tiling which is important for large surfaces!
-
Has the Dark Mod team considered making (!copyright infriction!) and (!copyright infriction!)?
Sorry I mean the Mantipopula and Kangrejoludia?
Why would you even want them in TDM? This is not a manga-science-fiction mod. I'm pretty sure if you look around, you'll find more suitable game mod for such type of creatures.
-
brush has some obvious texture tiling on the top of the hair.
if you want to make it really *cool* you can add some alpha mapped layer around the hair to make some loose, single hair. but on the other hand - some models don't need hours of spending on them... it looks OK like it is. (except for that tiling, I mean).
-
I uploaded new version of moveable boat model - inside bottom of the boat is raised significantly, to avoid water clipping.
-
For some reason D3 items set this rather high, ~0.2 maybe to emphasize things bouncing around so the player would say "OMG Physics!!" But in reality most things don't bounce around like a rubber superball. I've been using a bouncyness of around 0.02 for most objects.
Yes, that's the thing that I have no freaking idea what numbers would be OK for what type of material.
air friction was left such high after I noticed no impact at all. Those values are actually not the best I found but just left as they were when I ended experimenting. As I said - physics is not my strong side and I felt like I was wasting my time, so I gave up. I'd be happy if somebody else finishes that moveable boat declaration.
But if you need diffrent collision model, I can make it, no problem. Just give me suggestions to the shape.
It may be a better idea to use an AF for this as then you could have an inside to the boat rather then having it a platform. With the AF you can just put bones on each side to act as the collision for the walls of the boat and have the constraints set to really high.Well, feel free to try it but real boat is basically impossible in nowadays game engines, anyway - it wouldn't move the water out from underneath the boat. So, whatever we think up will have to be fake anyway.
-
Cool! Would be great to have it working. (a bit bigger I suppose could be better for easier placing items on plates, especially when you do strings). I can see some interesting gameplay possibilities with working scales.
-
you can remove it with alternative skin. (change it to nodraw)
-
I think you need either a "colored" keyword or:
red parm0 * 0
green parm1 * 0.8
blue parm2 * 0.1
in there.
Color keyword is fine. Colored is used only if you want to control RGB and alpha from the editor/game through shader parametres.
Baddcog - last parametr does change the alpha indeed but there's nothing telling the renderer to actually use alpha. I think there's word translucent missing at the first part of the shader. But I'm not an expert either...
-
Brushes and patches don't have spawnargs, it was the worldspawn you were assigning that tag to actually. All other world brushes carry the same spawnarg, check it out.
Oh, yes. Now I know what you meant... Somehow I knew it wouldn't be that easy...
I think that it still would be better to have it working only with entieties rather than nothing, but hopefully you'll find a way to get around that problem.
-
The problem with grouping by spawnargs is that it only works for entities -- you would never be able to group a number of brushes or patches together, because they are all part of a single entity (the worldspawn).
But tagging is not a grouping really - it doesn't change the structure of map objects. And you can assign some spawn_args (=tags) to brushes as well, so it should work. I added some "tag"" to one of my brushes, it was added to the list, not ignored, it was saved with a map, compiled with no problems, so actually the core functionality is there already - we CAN add "tags" to brushes or entities. But we cannot select by spawnargs (=by tags, as far as I know).
It would be actually useful feature not only for tagging - you could use it by selecting all entities with f.e. "noshadows" spawn_arg etc.
Missing any form of grouping feature is really bad. It takes ages to select complex group of entities - using brush for selecting usually ends up with selecting more than you need and than you have to spend some time on unclicking unwanted entities and so on...
Tagging has another advantage over regular grouping - you could select f.e. only books in whole map. And together with filtering option you could hide everything except books, so you could focus on editing them only.
-
I don't mind if tags would be a string as a property of some spawn_arg or they would be unrecognised spawn args (without a need for a property to put in). It's just a matter of aesthetics and functionality (practice would tell it).
The thing is if selecting objects in DR by those tags is possible or not. For me it looks quite easy to do and gives really great possibilities of organizing stuff in the scene.
PinkDot's textures
in Art Assets
Posted
No, it's not yet - to complete the set I have to make some wood texture matching those wooden beams - you really need to add some support beams or something, you know. I'll do it as soon as I can, so watch out for them. (in the main SVN, not beta).