Map shadows problems(and traffic problems)

[RaoulEmilian]

Hello, i am a 3d modeler and i love racer driving simulator so i started to make a area of my city but i have problems with shadows in CG verion. At the edges of the buildings the shadows look strange. Isn't there a way to make sharp and clear shadows and the light do not pass through the object edges?

And also i made a fast traffic loop line with 53 waypoints just to see how it works and it doesn't work, i have that traffic ini(it is a notepad for you just to verify it because this site didnt allowed me to upload it with the ini extension) uploaded here that you to verify and also i have that car: bmwx6m in cars folder. I will show you a screenshot with the racer traffic line( it is a loop i used the forward and bound the 53 waypoint with the 0 waypoint so should be fine). So why my simple taffic doesnt work? When i enter in game no traffic car appears.
Thank you in advance, Raoul, Romania.

 

[Stereo]

Light passing through edges is odd... I would expect a little bit but not that much. The reason it happens is that there's a small offset in the shadows cast - basically because the shadow map is a bunch of steps, like
|_
....|_
........|_
(since it's composed of discrete pixels)
In order to not have the 'points' on the ridge bleed through the front surface of objects, the offset shifts them back slightly.

(atomic blast style illumination courtesy of 'sun ambient 0 0 0' in the console)
The only place I'd expect shadows to fail, though, is on surfaces facing the sun - in this picture, the road's facing the sun, and the wheel's shadow doesn't quite match up.

Have you checked that the normals are pointing the right way?




To enable traffic you need the loop (which you've got), you need starting grid points, and you also need to enable specifically some traffic vehicles. TrackEd won't do this for you. It's just a simple section at the top of traffic.ini:

cars
{
  car0
  {
  car=carfoldername
  waypoint=0
  }
  car1
  {
   ...
  }
  ...
}

The starting grid is in special.ini. It's possibly a glitch, but cars start on grid positions instead of the waypoints defined in traffic.ini atm (although they will warp back to traffic waypoints if they get too confused). You need

grid
{
  count=25
  pos0
  {
    from 
  ...
}

At least a position per traffic car.

 

[RaoulEmilian]

Thank you for fast answer. I used the 3ds max dof exporter plugin and also the normals were exported. So i think there should be my mistake in 3d modelling , i am not sure yet how i can modify normals in 3ds max and what they are exactly. Can you explain me?

 

[Mr Whippy]

Which 3DS Max exporter did you use?

Some1's exporter, or the Racer Content Tool one?


I've had issues with both with regards normals at one point or another, with odd combinations on the modifier stack, and then at other times while using a multi-sub material.

Just as a check, try export the walls as unique material objects via ASE, then into modeller.exe, then export to DOF that way. Usually that clears up any DOF normal issues.

Alternatively, before exporting save your track, select the geometry to export, and reset x-form, then collapse back to editable mesh. Then export.


Generally though there is bleeding on edges due to shadows.

Shadows might look soft because of the resolution of the shadow mapping at that location relative to the car. If you drive the car up to them do they still look soft?

There is a problem in Racer still where shadows are softer nearer the camera than further away when looking at the car at least, so the effect you see may be worse than it would be if the bug were fixed. I'm not sure though.


Keep up the good work

Dave

 

[RaoulEmilian]

Yes when i come closely to the shadows , with the car, they start to look good but from distance they aren't. I will try the x-form method. Thank you.

 

[Mr Whippy]

Yeah, if you hover the camera away from the car to another location then the rendering engine is still prioritising the shadow sharpness around the car where the camera originated.

That works quite nicely then for sharp shadows around the car if you hover the camera away then look back at the car for a screen shot...
It does mean though that the shadows eventually go a bit blurry as you move away.

In practice there isn't much we can do about that. There can only be one focal point for shadows and they can either be at the car (for car driving views), or at the track camera origin (for track camera fly-bys)


Given time shadows will get better. By the time we have 8gb gfx cards we'll be able to run big res shadow maps and have things look much better... still a few years away yet though

Dave

 

[camsinny]

Also check your scale.
1 unit in max should equal 1 meter.

 

[Mr Whippy]

I still don't like Max units.

The spinners seems to retain a global scale even though you might use small units.

I'm using 1cm system scale now for most stuff car related, and a system scale of 1m for stuff like tracks.

Then I keep the unit scale at cm for cars, and metres for tracks etc.

It kinda starts to not make sense then having a unit scale because the system scale determines the auto-values of spinners (ie, one click on a spinner seems to be 1/100th of the system scale, not unit scale)... this makes spinners become less useful the larger the disparity in system vs unit scale.


In any case it seems Max is then happy to 'convert' system units to the appropriate ones at export if you just change unit scale at export... but even that is stupid.

Ie, right now I model cars in cm, export in cm, and then scale / 100 in modeller.exe

If you try model in metre system and unit scale all the spinners are horrible for details on cars.

System set to metres and units to cm and it's just the same problem, but the values are 100x bigger and spinners just jump 100x bigger steps.



I guess however you look at it the only ideal solution is to set system/units to the same unit and that is one which suits what you are making. As long as that works for your workflow/pipeline then great.


But I just don't get why 3DS Max doesn't have unit scale determine the spinner increments/steppings etc, rather than system scale... then it wouldn't be a problem at all.


Hmmmm, unless I'm doing something wrong still

Dave