torcs-users Mailing List for TORCS - The Open Racing Car Simulator

Hi
> Thanks for the help. Unfortunately, the old buildings seem to be beyond
> repair. So one step forward, several steps back. Second, the use of
> single-sided surfaces produces weird results, namely a building
> wall/roof/door (also fences and walls of different kinds) that's
> single-sided looks completely transparent from the other side, apparent
> in the F4 view in the game when I check the created building(s). That's

Yes, that is called back-face culling, IIRC I mention that in the car 
creation video. It is very easy to handle:
- First model the object from outside (e.g. car rooftop in the car tutorial)
- Then copy the object and flip the normals

This has the advantage that the front and back sides are correctly lit, 
if you use 2 sided surfaces the lighting is just right for one side, 
because the lighting is just calculated once per vertex.

A second advantage relevant for some cases is the the front and backside 
can have different textures assigned.

The disadvantage is of course the higher load due to duplicated geometry.

Important (maybe you are aware of it, just to make sure): If you do not 
take special care during modeling, you have to adjust the surface 
normals at some point (such that they all point to the outside for a 
closed shape). In ac3d (and all other modeling tools) you can switch on 
the visualization of the normals. If you work with single sided surfaces 
form the beginning you immediately see when a surface is the wrong way 
round, because it is simply transparent.

> of course unwanted, and forces me to switch them back to a two-sided
> surface. I don't know what that's all about. So far, the two-sided
> buildings, the dull, uninspiring boxes I've added, haven't had the same
> light problems as the earlier experiments. I guess I have to steer clear
> of those and stick with basic structures for now, much as it clashes
> with my mindset.

Don't give up, if you master to get a correct lit/shaded box you know 
enough to master more complex objects.

> About the tutorial pages, I wonder if the elevation and relief files are
> absolutely necessary for a functional track. I remember reading about

No, they just help controlling the generation of the terrain. Relief 
files allow you to preset contour lines for the terrain (so the mesh 
generator generates the mesh using the points on the contour lines).

Elevation files help you to control the height of the terrain.

> those a long time ago, but haven't created any for the previous versions
> (both .ac and .acc), and haven't noticed any graphical issues there. The

Yes, they are not required, they just help to get closer to the desired 
terrain right out of the generator without manual modeling.

> whole shadow map business went over my head. For my tracks, I've either
> had a simple blank image (some hue of white like #f4f4f4) or used the
> track outline as the basis of the shadow map, tried and erred in the
> shadow2.rgb file until the track's/shadow's position has been accurate.
> Understandably, that might not be particularly realistic, but when all
> else fails, there's only experimentation.

Yes, that is tricky, in the track tutorial by Vicente he explains how to 
do it with Blender:
http://www.berniw.org/aboutme/publications/build_your_trocs_track_in_20_minutes_v2.odt

I explain it here how I do it with povray:
http://www.berniw.org/trb/forum/showthread.php?topicid=163

> There will be instructions on the website for any volunteers who know
> their way around these objects (and obstacles). Useful contributions
> would probably speed up this whole development process, but I'm not

An open license like the GPL/FAL would make it easier to work together 
and to share, but of course this is your choice. I think free licenses 
are really beneficial at the point where the original author loses the 
interest, so other people can continue the work even if the original 
author cannot be contacted anymore.

> holding my breath (It's the instant gratification age after all). The
> (dozens of) tracks themselves are diverse, raceable, interesting, often
> quirky and difficult enough. Who knows when they're ready for release.

Kind regards

Bernhard

Thanks for the help. Unfortunately, the old buildings seem to be beyond 
repair. So one step forward, several steps back. Second, the use of 
single-sided surfaces produces weird results, namely a building 
wall/roof/door (also fences and walls of different kinds) that's 
single-sided looks completely transparent from the other side, apparent 
in the F4 view in the game when I check the created building(s). That's 
of course unwanted, and forces me to switch them back to a two-sided 
surface. I don't know what that's all about. So far, the two-sided 
buildings, the dull, uninspiring boxes I've added, haven't had the same 
light problems as the earlier experiments. I guess I have to steer clear 
of those and stick with basic structures for now, much as it clashes 
with my mindset.

About the tutorial pages, I wonder if the elevation and relief files are 
absolutely necessary for a functional track. I remember reading about 
those a long time ago, but haven't created any for the previous versions 
(both .ac and .acc), and haven't noticed any graphical issues there. The 
whole shadow map business went over my head. For my tracks, I've either 
had a simple blank image (some hue of white like #f4f4f4) or used the 
track outline as the basis of the shadow map, tried and erred in the 
shadow2.rgb file until the track's/shadow's position has been accurate. 
Understandably, that might not be particularly realistic, but when all 
else fails, there's only experimentation.

There will be instructions on the website for any volunteers who know 
their way around these objects (and obstacles). Useful contributions 
would probably speed up this whole development process, but I'm not 
holding my breath (It's the instant gratification age after all). The 
(dozens of) tracks themselves are diverse, raceable, interesting, often 
quirky and difficult enough. Who knows when they're ready for release.

Sincerely,
stockroom staff
ST Creative Designs
http://stcreativedesigns.fhero.net/

Hi

> This is a recurring problem that seems to have ruined the already
> onerous task of adding 3D objects to tracks. It would be great(ly
> appreciated) if somebody could suggest a viable solution, so I wouldn't
> have to bulldoze all the gazillion buildings created or pull the plug on
> this fruitless exercise.
>
> Here's an example screenshot from one of the tracks:
> http://stcreativedesigns.fhero.net/img/stcd-build00.png

Ok, first take a deep breath, as you can see from several examples, it 
is possible to add objects which get lit properly, and I try to figure 
this out together with you.

> The red arrow points at the weird discoloration/brightness that appears
> on just about every building created on lots of tracks. Does anybody
> know what's causing that, and is there anything to fix? That happens
> with buildings of various shapes and sizes. As a hopeless experimenter,
> it's difficult to say what went wrong there. I tried "Optimize vertices"
> and "Optimize surfaces" for the whole building (group), no change. I
> also thought it might be caused by the stupid crease 45.000000 lines
> that always get added to the .ac file after you edit the track, but now
> that I went and removed all of that extra junk from one track.ac file,
> it turned out the same graphical BS (as seen in the example image)
> remained there. I've edited the various light settings (amb, emi, spec,
> shi) at the top of the .ac file and returned to the track, but nothing's
> worked.

Basically a lot can go wrong when doing modeling, before we look into 
your case some general infos/posts:
- Car modeling tutorial, basically the splitting and lighting part 
applies for all objects in TORCS, see http://youtu.be/JFaWNe8jcMc
- http://www.berniw.org/trb/forum/showthread.php?topicid=163
- 
http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/doc/tutorials/track/index.html?revision=1.2&pathrev=r1-3-1

For TORCS you have to:
- Set ac3d crease angle to 180 in the preferences (then the rendering in 
ac3d is as close to the rendering in TORCS as it can get)
- Use only one material
- Take care when extruding that you are not leaving "inner surfaces" 
behind (confuses the lighting/shading)
- Use only single sided smooth shaded surfaces
- And some more, have a look into the car tutorial linked above

Ok, now lets have a look into your screenshot, it looks very confusing, 
I could imagine that it is a combination of weird surface subdivision, 
wrong surface types and normals and "inner leftovers" and broken object 
organization.

> So now, after these predictable failures, I'm looking for useful advice
> from more experienced 3D manipulators. This is not a graphics
> card/graphics settings issue: tracks without those 3D objects added
> don't exhibit that discoloration. Section "Graphic" in the track.xml
> file shouldn't be at fault, either: editing the light values there made
> no difference. And this only affects buildings, not for example
> grandstands or billboards.
>
> I wonder if the surface manipulation of a building could somehow have
> messed it up: selecting a surface/surfaces, often using "Divide" to get
> smaller areas of the surface, then "Cut away object" (to be able to add
> a door or window), then naming that object and choosing some specific

Yes, that is the way to go.

> texture (mainly door or window). But if this method produces those
> graphical anomalies, how are you supposed to add doors and windows to a
> building? A separate rectangle placed in front of another object, like a
> door before a building, often caused ridiculous and disturbing
> flickering. Furthermore, there are buildings on these tracks with doors

Yes, thats Z-fighting, you should not do this. Depending on the viewing 
distance it can be appropriate in some cases to just paint the door on 
the texture though.

> and windows added like described, and they, for some reason, don't have
> that bright discoloration. So confusing, so frustrating, so tiresome to
> bang your head against that wall.
>
> More relevant info can be provided if needed. The .ac files, however,
> won't be distributed.

Hmm, too bad, so you will never release the tracks in any form (acc is 
just a combination of multiple ac files, it is not rocket science to 
convert it back)?

Kind regards

Bernhard

This is a recurring problem that seems to have ruined the already 
onerous task of adding 3D objects to tracks. It would be great(ly 
appreciated) if somebody could suggest a viable solution, so I wouldn't 
have to bulldoze all the gazillion buildings created or pull the plug on 
this fruitless exercise.

Here's an example screenshot from one of the tracks: 
http://stcreativedesigns.fhero.net/img/stcd-build00.png

The red arrow points at the weird discoloration/brightness that appears 
on just about every building created on lots of tracks. Does anybody 
know what's causing that, and is there anything to fix? That happens 
with buildings of various shapes and sizes. As a hopeless experimenter, 
it's difficult to say what went wrong there. I tried "Optimize vertices" 
and "Optimize surfaces" for the whole building (group), no change. I 
also thought it might be caused by the stupid crease 45.000000 lines 
that always get added to the .ac file after you edit the track, but now 
that I went and removed all of that extra junk from one track.ac file, 
it turned out the same graphical BS (as seen in the example image) 
remained there. I've edited the various light settings (amb, emi, spec, 
shi) at the top of the .ac file and returned to the track, but nothing's 
worked.

So now, after these predictable failures, I'm looking for useful advice 
from more experienced 3D manipulators. This is not a graphics 
card/graphics settings issue: tracks without those 3D objects added 
don't exhibit that discoloration. Section "Graphic" in the track.xml 
file shouldn't be at fault, either: editing the light values there made 
no difference. And this only affects buildings, not for example 
grandstands or billboards.

I wonder if the surface manipulation of a building could somehow have 
messed it up: selecting a surface/surfaces, often using "Divide" to get 
smaller areas of the surface, then "Cut away object" (to be able to add 
a door or window), then naming that object and choosing some specific 
texture (mainly door or window). But if this method produces those 
graphical anomalies, how are you supposed to add doors and windows to a 
building? A separate rectangle placed in front of another object, like a 
door before a building, often caused ridiculous and disturbing 
flickering. Furthermore, there are buildings on these tracks with doors 
and windows added like described, and they, for some reason, don't have 
that bright discoloration. So confusing, so frustrating, so tiresome to 
bang your head against that wall.

More relevant info can be provided if needed. The .ac files, however, 
won't be distributed.

Sincerely,
stockroom staff
ST Creative Designs
http://stcreativedesigns.fhero.net/

----- Bernhard Wymann wrote:
> Hi David
> 
> You might looking for adjusting the inertia of the car, the cg hight, 
> roll centers and the tire properties. I created a video regarding this 
> some time ago, maybe you already know it:
> http://youtu.be/H75kZ37j9o4
> 
> Kind regards
> 
> Bernhard
> 
Thank you. The video was very informative; I viewed all of it.
I recommend these videos for anyone who wants to understand
TORCS code and functionality. These videos are the
"TORCS Reference Manual."

Maybe the 'next thing' in 'open source' is 'theory of operation videos'!

Sincerely,
David Savinkoff

Hi David

You might looking for adjusting the inertia of the car, the cg hight, 
roll centers and the tire properties. I created a video regarding this 
some time ago, maybe you already know it:
http://youtu.be/H75kZ37j9o4

Kind regards

Bernhard

On 01/01/2015 10:06 PM, David Savinkoff wrote:
> Hi Bernhard,
>
> After seeing your explanation, I agree with you. However
> I do have some opinions.
>
> I submitted the patch because, at first glance, it looked
> like x and y may have been swapped... and the car
> actually drives better (especially drifting, and dirt tracks).
>
> I attempted to make sense of my patch. Here are some
> possibilities:
>
> * Swapping the x and y axis may subtract some rotation from
> car and make it more driveable ( what a hack!).
>
> * I changed the code to the following, and the car still
> drives OK.
> car->corner[i].vel.ax = 0.0;   //- car->DynGC.vel.az * y;
> car->corner[i].vel.ay = 0.0;   //car->DynGC.vel.az * x;
>
> When I drift torcs, it feels like too much energy goes into
> rotating the car, and not enough into going forward. As if
> the bumper is plowing the ground. I actually had an old
> Cadillac that would plow the sawdust I drove in. When the
> pile got over the bumper, the car would simply dig in
> (it could not rotate).
>
> If you could point me to the right part of torcs, maybe I'll
> find what I'm looking for. Thanks.
>
> Sincerely,
> David Savinkoff
>
> ----- Bernhard Wymann wrote:
>> Hi David
>>
>> I reviewed the suggested change, but I think it is wrong (I think the
>> original code is right).
>>
>> Simply assume a "1-d car" (a simple line from top), with one corner at
>> (x,y) as (1,0) and an angular velocity around the z-Axis := vz.
>>
>> So the speed of the corner relative to the rotation center is in y
>> direction r*vz, where r=x=1. I cannot see a flaw in this.
>>
>> With your change you would get a movement in x direction although the
>> radius in y direction is 0, that does not make any sense to me.
>>
>> Other thoughts, other opinions?
>>
>> Kind regards
>>
>> Bernhard
>>
>>
>> On 12/18/2014 02:31 AM, David Savinkoff wrote:
>>> Hi,
>>>
>>> TORCS was fueling my high velocity entertainment when road rage set in
>>> and I had to glare at the source code to calm down.
>>>
>>> I think I found a bug.
>>>
>>> The car drives much better now.
>>>
>>> Sincerely,
>>> David Savinkoff
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Torcs-users mailing list
>>> Tor...@li...
>>> https://lists.sourceforge.net/lists/listinfo/torcs-users
>>>
>>
>
>

Hi Bernhard,

After seeing your explanation, I agree with you. However
I do have some opinions.

I submitted the patch because, at first glance, it looked
like x and y may have been swapped... and the car
actually drives better (especially drifting, and dirt tracks).

I attempted to make sense of my patch. Here are some
possibilities:

* Swapping the x and y axis may subtract some rotation from
car and make it more driveable ( what a hack!).

* I changed the code to the following, and the car still
drives OK.
car->corner[i].vel.ax = 0.0;   //- car->DynGC.vel.az * y;
car->corner[i].vel.ay = 0.0;   //car->DynGC.vel.az * x;

When I drift torcs, it feels like too much energy goes into
rotating the car, and not enough into going forward. As if
the bumper is plowing the ground. I actually had an old
Cadillac that would plow the sawdust I drove in. When the
pile got over the bumper, the car would simply dig in
(it could not rotate).

If you could point me to the right part of torcs, maybe I'll
find what I'm looking for. Thanks.

Sincerely,
David Savinkoff

----- Bernhard Wymann wrote:
> Hi David
> 
> I reviewed the suggested change, but I think it is wrong (I think the 
> original code is right).
> 
> Simply assume a "1-d car" (a simple line from top), with one corner at 
> (x,y) as (1,0) and an angular velocity around the z-Axis := vz.
> 
> So the speed of the corner relative to the rotation center is in y 
> direction r*vz, where r=x=1. I cannot see a flaw in this.
> 
> With your change you would get a movement in x direction although the 
> radius in y direction is 0, that does not make any sense to me.
> 
> Other thoughts, other opinions?
> 
> Kind regards
> 
> Bernhard
> 
> 
> On 12/18/2014 02:31 AM, David Savinkoff wrote:
> > Hi,
> >
> > TORCS was fueling my high velocity entertainment when road rage set in
> > and I had to glare at the source code to calm down.
> >
> > I think I found a bug.
> >
> > The car drives much better now.
> >
> > Sincerely,
> > David Savinkoff
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Torcs-users mailing list
> > Tor...@li...
> > https://lists.sourceforge.net/lists/listinfo/torcs-users
> >
> 

Hi David

I reviewed the suggested change, but I think it is wrong (I think the 
original code is right).

Simply assume a "1-d car" (a simple line from top), with one corner at 
(x,y) as (1,0) and an angular velocity around the z-Axis := vz.

So the speed of the corner relative to the rotation center is in y 
direction r*vz, where r=x=1. I cannot see a flaw in this.

With your change you would get a movement in x direction although the 
radius in y direction is 0, that does not make any sense to me.

Other thoughts, other opinions?

Kind regards

Bernhard


On 12/18/2014 02:31 AM, David Savinkoff wrote:
> Hi,
>
> TORCS was fueling my high velocity entertainment when road rage set in
> and I had to glare at the source code to calm down.
>
> I think I found a bug.
>
> The car drives much better now.
>
> Sincerely,
> David Savinkoff
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Torcs-users mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>