Track editing progress notes
#61
Here's the Holiday Inn hotel. Gaining more confidence with building .3DO files.


Attached Files Thumbnail(s)
   
Reply
#62
Trackside objects are looking good! Keep up the excellent work.
_________________________
Check out the IndyCar II Questionnaire!--> http://www.icr2.net/forum/showthread.php?tid=692
Reply
#63
(04-09-2020, 02:36 AM)checkpoint10 Wrote: Here's the Holiday Inn hotel. Gaining more confidence with building .3DO files.

I'll take a room on the top floor!

Nice job. When I saw it I had the biggest smile all day! (I am working on the AI and text files myself, I fixed a bunch of problems so far and have been doing race testing)

Do you think you can understand what is wrong with the rio track? It would be nice to fix it.
Reply
#64
Okay let me go back into Rio and see if I can report back what might be going wrong there. At least I can look at it more intelligently than last time!
Reply
#65
Here are the humble beginnings of Rio. I have widened the track to match the widths that I measured on historic Google Earth imagery and brought the infield armco closer to the track.

I spent a lot of time thinking about ways to optimize my workflow. With Caesars, my approach was to do everything upfront in OPE, let the N2toICR2 converter run, and pretty much that was it. This is not great because my final palette is at the mercy of the N2toICR2 tool - I cannot control what it does with palettes.

For Rio, I will take a hybrid approach of my Caesars workflow and the one that Pavel described. First, I have selected ICR2 Portland as the palette that I will use, because I like its asphalt and grass, and the blues and greens should be appropriate for the Rio scenery. I will use the default Portland's sunny.pcx as my palette for both the OPE version and final product. This is much better than my previous approach of dealing with 3 palettes, here I only deal with one palette for most of the project.

N2toICR2 generates a ICR2 palette which I will not use, because it does not do a good job retaining enough colors for asphalt. So after conversion, I will copy the original sunny.pcx and all the mips that go along with it. I have a folder where I keep all the files I want to overwrite whatever the converter made. I have a script that automatically unpacks the converted track, copies those files in, and repacks the dat.

The advantage of using the same sunny.pcx in OPE is that I can still see for the most part what the colors will look like. I will have a bit of inconvenience in having to manually change the final 3DO colors in 3DOEd, but I have practiced doing that and it is not too bad of a process, even on the track 3DO where I would have to change the colors of all the track and walls. The Tutorial describes a technique for doing this. I will likely have to leave the track 3DO poly colors unchanged until the very end (i.e. release version) because the color changing cannot be automated. This probably means that on any alpha versions, the faraway walls and track may appear in strange colors.


Attached Files Thumbnail(s)
   
Reply
#66
I've never experienced issues with sunny.pcx. I can't really follow your workflow, so I don't know, where the problem come from.

My workflow was as follows. I took a sunny.pcx and eliminated all colours, except the game colours. After that, I made my texture images. I changed the image mode to paletted, and tried out, what's the minimum amount of colours with the image looks acceptable. Then I added these colours to the sunny.pcx. After I made this with all textures, I had a complete palette which I used to make all the .mip files. Important for all Photoshop users, Photoshop palettes have a reversed colour order.

For your problem with the polygon colours, you can use the same procedure, like for the objects. You can change the colours in the .3d file, and you can replace that part everytime, when you make a new .3d file. That part comes right after the object list, and looks like
nil : NIL ;
__Asphalt1__: [<0, 0, 0>, c= <178>];
__Asphalt2__: [<0, 0, 0>, c= <178>];
__Asphalt3__: [<0, 0, 0>, c= <178>];
__Asphalt4__: [<0, 0, 0>, c= <178>];
__Concrete1__: [<0, 0, 0>, c= <188>];
__Concrete2__: [<0, 0, 0>, c= <188>];
__Concrete3__: [<0, 0, 0>, c= <188>];
__Concrete4__: [<0, 0, 0>, c= <188>];
__Grass1__: [<0, 0, 0>, c= <205>];
__Grass2__: [<0, 0, 0>, c= <205>];
__Grass3__: [<0, 0, 0>, c= <205>];
__Grass4__: [<0, 0, 0>, c= <205>];
Reply
#67
My problem is that when I convert a track using the N2toICR2 tool, it will create a different sunny.pcx than what I had been working with. I am finding that N2toICR2-converted palettes cause my asphalt to lose color compared to the optimized palettes of the default ICR2 tracks (i.e. the converted palette doesn't have enough color to give the asphalt the subtle colors that it should have). So, I try to eliminate this problem by forcing my converted track to use a palette that matches with an asphalt texture that I took from another default ICR2 track. This then creates a new problem that some of the polys (most likely from the track.3do itself) will not be matched to the palette - in other words, all the color changes I make in the track.3d file and can see in OPE will ultimately be lost when I manually copy over another sunny.pcx after conversion. But I can fix this in 3DOEd easily enough.
Reply
#68
(04-12-2020, 06:31 AM)checkpoint10 Wrote: ....The Tutorial describes a technique for doing this. I will likely have to leave the track 3DO poly colors unchanged until the very end (i.e. release version) because the color changing cannot be automated. This probably means that on any alpha versions, the faraway walls and track may appear in strange colors.
For main track 3do it can be done. I will teach you later.


(04-12-2020, 03:48 PM)Dennis Wrote: I've never experienced issues with sunny.pcx. I can't really follow your workflow, so I don't know, where the problem come from.

My workflow was as follows. I took a sunny.pcx and eliminated all colours, except the game colours. After that, I made my texture images. I changed the image mode to paletted, and tried out, what's the minimum amount of colours with the image looks acceptable. Then I added these colours to the sunny.pcx. After I made this with all textures, I had a complete palette which I used to make all the .mip files. Important for all Photoshop users, Photoshop palettes have a reversed colour order.

For your problem with the polygon colours, you can use the same procedure, like for the objects. You can change the colours in the .3d file, and you can replace that part everytime, when you make a new .3d file. That part comes right after the object list, and looks like
nil : NIL ;
__Asphalt1__: [<0, 0, 0>, c= <178>];
__Asphalt2__: [<0, 0, 0>, c= <178>];
__Asphalt3__: [<0, 0, 0>, c= <178>];
__Asphalt4__: [<0, 0, 0>, c= <178>];
__Concrete1__: [<0, 0, 0>, c= <188>];
__Concrete2__: [<0, 0, 0>, c= <188>];
__Concrete3__: [<0, 0, 0>, c= <188>];
__Concrete4__: [<0, 0, 0>, c= <188>];
__Grass1__: [<0, 0, 0>, c= <205>];
__Grass2__: [<0, 0, 0>, c= <205>];
__Grass3__: [<0, 0, 0>, c= <205>];
__Grass4__: [<0, 0, 0>, c= <205>];

That's my way of working on track too. I create palette step by step for ICR2 track. I use same ICR2 palette and track textures mips but in N3 format inside OPE folder just to have correct looking track in OPE. But I never convert palette or textures with n99toICR2 converter.
Reply
#69
(04-14-2020, 06:23 AM)Pavel 69 Wrote: For main track 3do it can be done. I will teach you later.

I look forward to the lesson.
Reply
#70
In SGE If one day you have a banked turn that is made of 3 or more parts and it feels like rollercoaster between them even after tweaking the rotation (dragging the cursor left or right from the point to access that feature), you can smooth them this way :

(e.g. for a 6 parts turn, 3 ups & 3 downs)

Highlight first part by left clicking it, hold down Ctrl key and then left click the second point of that part. A HUGE arrow will appear. Then left click on the second point of the third part ("top of bank"), the three parts will now be smoothed together, no more bumps.

Then down banking same thing with second point of part 4 and second point of part 6.




Also .mrk data gets deleted if you come back in SGE to tweak stuff after you're done with SFE.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)