Messages

Work on the Skyline remains steady. The first screenshot shows the current car0 working model, which already is reasonably detailed, although it has only 120 polygons (will try to insert some extra details later on). Now I will focus mainly on the dashboard for a while. I tried to start one from scratch, and even found a nice strategy using masks and layers to sculpt it (the set of masks is shown on the second screenshot). However, as my image manipulation skills go, making a pretty dashboard from those elements will take long, so for the moment I'll probably start over and try to make a composite dashboard from elements available elsewhere, as Cody is doing for his Ranger.

I really like your dashboard , it looks very natural - I think I'll use this mix-and-match approach to design one for Skyline.

Great score, you will beat me easily (if you haven't already)...

Well, it was pretty hard - I had to pull a 37 streak at map mayhem...

Just noticed I (and Zak, and BJ, and maybe even JTK on the site) need to change the tags on the MMVII downloaded tracks to Böhm-Kalpen-Maass - as it is, our plays are being submitted to Felyx Maass, Oliver Kalpen, Detlev Böhm instead on last.fm ...

No comments so far about  , also know as Mark's new avatar...  =)           

And even if I don't think I'll ever get tired of the Moving Pictures cover (or of the actual album), I'll switch it a bit for something that might be a slightly harder guess...

Then I (alias Daniel Mlot) took the liberty to add you guys as well...

Now to wrap my head around the culling...

Beware not to get hit! (as your head won't be visible... )

(sorry for not sparing you from such a poor joke...)

Added both features in SVN, although this can already be done with existing 3d modelling software...

Thanks for catering to our requests so quickly!  Although I use Anim8or for heavier edition work Stressed 3D capabilities are quite convenient for adding small overlaid details and doing quick tests - exporting to .OBJ means losing culling data and the other flags, as well as often some polygon reordering. Speaking of that, I have one last solicitation (okay, you can kick me now... ): a widget for moving a polygon to an arbitrary position on the list - say, moving polygon #45 to position #110. The polygons shouldn't be swapped, however: in said example, polygon #46 should go to #45, #47->#46 and so on. This addition is important because of Z-bias, as it requires any overlaid polygon to be ordered directly after the base polygon. Fixing the order of a number of polygons can be a bit tiring sometimes, and that's one of the reasons why I often get lazy about exporting intermediate models to .OBJ... 
(PS.: And before I forget, I saw the improved material list, and it was a nice addition as well)

Hm, are you sure? It doesn't look like I reversed the change...

As expected, you're correct. I had commented out that line manually and then placed a backup of the file on src/shape, so SVN must have messed up a bit during the multiple updates. Problem solved, anyway...

Ha, i like this sort of game too - the one I knew was Traveler IQ (http://www.travelpod.com/traveler-iq). I'll do like Chulk and create a single-purpose account to check it then...

[are active only for specific regions of the space]

Only an idea for Stressed innovation: to make the car edition faster, it would be cool to have a special duplicating option which converts the new polygon to inverse X coordinates.

On that same line, one addition I'd propose would be vertex reordering in polygons, so it would be easier to flip their faces. Anyway, both major recent changes - culling data displays and weld coexisting vertexes - were really useful and help a long way in making Stressed a capable 3D editor for Stunts shapes, in particular for testing and experimentation. Just one small thing, Dstien: it seems you inserted back that 49x line on shaperesource.cpp which (tries to) export wheels as lines. Could you please revert it to r35 behaviour? Thanks in advance 

Now, on to further experimentation: after a lot of head-scratching, I have a reasonable, semi-functional, theory on how the four culling bit sets work. Explaining it tersely:

• As you're probably aware, polygons have definite front and back sides. Which is which can be identified by applying a "left-hand grip rule" (analogous to this, only done with the left hand instead of the right one - the four fingers are supposed to be parallel to the polygon plane and then be rotated in the sense vertexes are ordered on Stressed. The thumb will then be pointing outwards.). Accordingly to the front/back distinction, the polygon plane divides the viewing space in two halves: one with POVs (viewpoints/points-of-view) facing the front of the polygon and the other with backside-facing POVs. The function of the 2-sided flag is to make the engine take both faces, and POVs, as frontal.
• The four sets of culling data and associated flags are active only for specific regions of the space (or POV sets, if you prefer):
  
  
  
  • CH+: Front-facing POVs from above
  • CH- : Front-facing POVs from below
  • CV+ : Back-facing POVs from above
  • CV- : Back-facing POVs from below
  Definitions of "above" and "below" aren't completely clear, but they seem to refer to above and below the median horizontal plane of the polygon. I assume that's what Dstien meant with positive and negative viewing directions as well.
• There is a culling cutoff radius, which is approximately equal to 17 zoom steps when looking the polygon from above. The culling data sets only are effective outside of this radius. Within the cutoff, visibility is exclusively determined by sidedness (front-facing = visible; back-facing = not visible), and both the 15-bit data sets and the associated flags are disregarded.
• There is a vertical angle cutoff, about 7 camera steps away down from a fully vertical angle. Due to limitations of F3 camera angles, this was only checked for from-above POVs. It is reasonable to assume a similar cutoff should exist for the opposite direction though. For vertical viewing angles high enough to be beyond the cutoff, the 15-bit data sets gets disregarded, and visibility is exclusively determined by the flags associated to CH/V data appropriate for the current POV. If the flag is on, the polygon will be always visible beyond the cutoff (within the high vertical angle cone), otherwise it won't be visible.
• The 15-bit culling data sets only are effective outside of the cutoff radius and below the high vertical angle cutoff. As identified by Dstien and displayed by the disk representations in Stressed, they define visibility ranges for horizontal angles within the region where the current POV is located (frontside/backside and above/below).

The scheme presented above seems to work well in most usual cases, in particular for vertical or near-vertical polygons. Sometimes it's hard to assess whether the expected results are being attained or not due to limitations on the viewing angles available from F3 camera (that is specially annoying when trying to identify culling at POVs from below). Horizontal polygons sometimes cause trouble too: the theory partly breaks apart when trying to make downwards-facing polygons visible from above, for instance - it seems that CH+ and CV+ both need to be set in such case (a good, and annoying, demonstration exercise is attempting to, without using two-sidedness, make the floor of a car visible from above (after making the roof/hood invisible), or tunnel roofs for that matter...). Nevertheless, a number of common culling data patterns seem to make sense now: for instance, the fact that front-facing from-above POVs are the ones which are the primary concern most of the time when modeling a car explains why I previously though only CH+ was relevant. On the other hand, when looking at a car floor it becomes apparent it's CH- which dictates its visibility. Some of the trends when comparing CH+ to CH-, CV+, etc. for horizontal, vertical and oblique polygons also begin to make sense from that perspective (and thus a method for generating them might be viable), although it seems the values were indeed hand-edited to some extent...

Coulthard and RBR '06 in Buenos Aires. He spin the car pretty close to people in the widest avenue of the world, 9 de Julio.

Cool demo, that area would make for a very good street circuit I guess...
Although the conditions, unlike in the Buenos Aires demo, were far from ideal, I found this to be pretty awesome too. Driver was Robert Doornbos IIRC.
http://www.youtube.com/watch?v=YhF_Zp8nM7o
(And incidentally, we have a July 9th avenue in São Paulo too, the names being unrelated however. Anyway, the major avenue you'll see on the video is May 23rd (23 de Maio) instead.)

Glad to see you're still following us, Cody - and nice work on the Ranger!

this kicks ass

Seconded 

Nice event, and at Monza of all places!

After the inscription and a short briefing about safe driving (30 minutes), all the participants at the session (50 every 30 minutes) have made an absurd and comic run to the cars, in order to preempt the most powered.

Sort of a taste of vintage Le Mans? 

but I jumped into a white new Volkswagen Scirocco (1.4 160 HP  ))

Very respectable stats indeed! That sounds like a really cool car...

Does this mean you can only run Stunts through DosBox on Vista?
That is the death of Stunts. Unless Vista is quickly replaced by another operating system in which you can run it properly.

Well, XP can't run Stunts properly either (no sound without extra tools like VDMSound, which can slow the game quite a bit unless you have a fast computer). It's likely most contemporary newbies race on DOSBox already anyway... which is not so bad: technically, the emulation is almost perfect by now and, as computers get faster and DOSBox evolves, will tend to get even better. And that's not to speak of platform independence - Vista, Linux, Mac, you name it... The main issue, IMO, is to get newbies to be aware as quickly, easily and painlessly as possible of DOSBox usage with Stunts, for that is the future ahead of us.