Topic: SC4 Model Tweaker Development/Support thread (Read 80039 times)

cogeo · « **Reply #40 on:** April 17, 2009, 12:17:26 PM »

@jeronij: Working with such models is actually easier, as BAT (gmax or 3ds) isn't involved at all. In the pic below you can see a subway station of my Pedmall-Compatible Transit Pack (released on the STEX long ago).

(zoom-in to see details)

What is interesting here is that the pavement isn't really a texture, but instead a prop. The model is a simple 16x16 flat model with 1 Z/R. It integrates seamlessly with the pedmall tiles around it, which are actually networks (not lots); and this is expected, as it is displayed in the same way as the puzzle pieces, and references directly the very same texture. If I had just used a lot texture, I would had lighten it up, and then try hard to match the luminosity and contrast exactly, and I might still have issues with differences like "gammas". What is important here is that this model looks MUCH better than the subway, which is pixelated and jagged. And this is quite normal, because the texture wasn't processed in BAT (rendered) but instead used directly after photoshopping (or PSP-ing

). I think it would be worth to give it a try.

@SimFox: Really sad to hear this. The problem is that I don't have Vista installed, to test this out. Some things that might help:
- You can send me your model (also describing the steps you have taken) to test it on XP, or test it yourself, if you still have an XP installation. This can tell if the program has a problem processing this specific file (which would them be a good test case), or if it's instead a platform-related issue.
- As far as I know (I may be wrong) Vista has more that one complatibility modes for 32-bit applications; maybe try another one, and U would say check the options for the reader (they use the same S3D.dll).
- Maybe try to modify only one S3D file, and only one zoom level, ie try to break it down, to identify which part exactly is causing the problem.

I could send you test/debug versions (dumping messages) so that we can identify what causes the problem, but this is considerable work and requires synchronisation, ie we should arrange it and be both online for many hours; and the result is not guaranteed, if the problem occurs in a system call or a call to an external library, most probably I will just "conclude" that nothing can be done. Finally I don't know if this is worth all the effort, maybe it would be much more practical to send these to someone running XP, to make the conversions for you.

sithlrd98 · « **Reply #41 on:** April 17, 2009, 12:45:43 PM »

Just to let you know , the program does run fine under x64 XP , but I have not tried under my x64Vista install yet.

Also , I was wondering if you had any plans to include an easier way to center of-centered props and vice versa?(that would almost be the holy grail!)

Jayson

cogeo · « **Reply #42 on:** April 17, 2009, 01:08:23 PM »

I haven't really considered doing this. It's actually something very specialised, a niche, i would say. Do you think it's really worth? How many off-centered models do you have to process?

jeronij · « **Reply #43 on:** April 17, 2009, 02:00:20 PM »

Cogeo, thanks for your tips about 3ds's

Btw, I'd say that sithlrd98's suggestion would also be a very nice one. Imagine the situation (one of my ongoing projects) --> I want to float a small fleet of fishing boats.... only buildings, no props, can be placed on the water. There can be only one building per lot. Most of the existing boats props are offset to adjust to their respective original lots... I just can dream a solution which would allow us to relocate the offset props to our convenience, and then merge several models into a single one (the small flet) and make my floating building ¡¡¡... I think such a tool would be a really unvaluable help for all the devoted lot makers and modders out there

buddybud · « **Reply #44 on:** April 17, 2009, 03:07:12 PM »

This is some excellent work. I was wondering if it would be appropriate to include an ability to either flip or rotate models also. This would be great for network models. You would have to apply trig functions to the vertices for the transformation and either alter uv settings or triangles to deal with textures.

Just a thought.

Bud.

cogeo · « **Reply #45 on:** April 17, 2009, 03:55:20 PM »

Hi again,

I have just uploaded a newer version of the tool. The executable should now be very close to what I had originally coceived as Version 1.00. It should be working without problems, so by now please report any of your findings as bugs or omissions.

The download link is <Get the official version from the LEX>

Changes from the previous version:
- The Set Transparency command now applies to 1-Z/R models too, and has an additional option for the "Depth Func".
- The program now re-creates the DIR file, if needed.
- The Help file is updated, all unneeded topics were removed, and there is now help on using the commands and explaining the operations (there is still quite much work left).

Still need to be implemented:
- In the help file complete some missing or incomplete topics - I would welcome any contributions here.
- Installer.

Some Notes:
- The program doesn't change file associations for any file type (it's not a main modding tool, so this wouldn't be right). However it's quite simple to use, you can use the standard File Open command, or drag-and-drop.
- All information in the registry is stored under "HKEY_CURRENT_USER\Software\Cogeo\SC4 Model Tweaker". To fully uninstall the tool, you have to delete these entries too.

INSTALLATION
- There is no installer for the time being, you have to copy the files under a new folder and create a shortcut manually.
- If you are upgrading from version 0.80, no other actions are required.
- If you are upgrading from version 0.50, you will have to open the registry editor (in your Windows Taskbar select Start->Run, and type-in regedit), go to "HKEY_CURRENT_USER\Software\Cogeo\" and delete key "SC4 Model Tweaker" (and its subkeys). This step is required before installing the new version, otherwise some menu commands may not be displayed, as the program stores there the "personalisation" oprions of the old version. Then overwrite the installed files with the new ones.

sithlrd98 · « **Reply #46 on:** April 17, 2009, 09:49:14 PM »

Its not so much quantity of models , its actually doing the grunt work! See, I was wondering if , since you have an app that can do the first part of what this tutorial MODding rendered SC4Models can do , I was hoping that maybe,possibly,the second part could also be automatic , even though I am only messing with a small model presently , but would like to get into some of the heavy stuff! I don't necessarily mean having the program re-assign new IIDs for the s3d or FSH files ,(if you want both) since in reality this would create a new model... that's the easy part!
Please keep in mind that I am not a BATer, and only have 1/10000000% knowledge that some of the others who are/have commented on matters such as this, I am only curious since you and other programmers can make some very useful tools , which is very cool , and very appreciated!

Jayson

cogeo · « **Reply #47 on:** April 18, 2009, 05:04:41 AM »

Replies to your posts:

@sithlrd98: Maybe this could be done but as a part of a more general "Move Model" or "Shift Model" function. Moving a model is simple and straightforward. But "centering" a model is rather tricky and lacks a definition. How could the centre of the model be determined? I can think of two ways, one based on the extreme x and y coordinates of the (LODshell's) vertices, and another one based on the average x and y of all vertices (kinda "centre of gravity", though strictly speaking the actual centre of gravity (or mass centere) is something different, and very hard to calculate for such models). For models with 20 Z/R views (normal BATs) this is even more complicated, as the models are not "complete", ie they contain only the polygons visible in each specific view (they lack the "back" faces). So the algorithm should examine all 20 Z/R files to determine the centre of the model, and then apply a shift operation with the proper values, so that the centre moves to (0,0). Still, this would work well only for models with symmetrical LODshells with respect to both X and Y axes. For example, it wouldn't work for models like streetlights (centered a the ligtpole). For such models none of the two algorithms would be satisfactory. Any sugestions?

@jeronij: As said above, a "move" or "shift" function is in the plans. I'm considering of a "merge" function too, this would be usefull for making bridges - I think you are aware of the technique of making the road or rail texture a model and merging with the bridges models (resulting in much better-looking network textures).

@buddybud: I'm considering such operations too. For 20-Z/R models this is not possible though, because of the missing back faces. But it is possible to perform another kind of operation (let's call it "Reorientate"), namely renumbering the instance IDs (for example 0x-----400 would become 0x-----410, 0x-----410 would become 0x-----420 and so on). This way it is possible to effectively "rotate" such a model by multiples of 90°. But for 1-Z/R a full rotation (or flipping, or mirroring is possible). For 90°-multiple rotations using trig functions is not even required, and performing simple coordinates changes is the prefered way (for such rotations the sin and cos functions are always 0, 1, or -1). For example, rotating a model by 90° clockwise means just setting x = y and y = -x. Do you really need rotations that are not 90°-multiples? I can only consider 45° for network models, though I really doubt if diagonal models are just orthogonal models rotated by 45°, some adjustments (esp width) are still needed, I think. Also I'm not sure about textures and triangles, shouldn't just moving the vertices be enough?

jeronij · « **Reply #48 on:** April 18, 2009, 06:49:36 AM »

Hello again, I donwloaded the .90 versions and installed fine and runs fine as well

I tried to run the transparency tool in the previously "trasnparented"

... model, just to change the depth parameter. However, it seems the tool is not able to recognize it now. It does not matter what I try, the tool shows a warning, no changes were made, and this is the error message:
"0x5ad0e817 0xf9730eaa 0x00030000 Mat= 0: No action taken - Unrecognisable settings pattern" <-- one of these for every .3ds
I tried to remove the transparency, and process it back, but I get the same error when I try to remove it

Do you have some idea about what's going on

... ??

You are right, I am aware of that technique for making the bridges decks, but at the time I tried it, I wasnt able to obtain a satisfactory result, or better that the result with BAT models

Regarding the centering issue, what about three sliders, X,Y&Z. They'd move the whole model on the desired direction, so the user can center it "by hand". just a quick suggestion

cogeo · « **Reply #49 on:** April 18, 2009, 07:17:04 AM »

Jeronij, send me the model to take a look (my mail address is public). Recognising the transparent state now depends on the setting for the Depth Func. Take a look in the help too.

I don't understand what you mean about centering. What's the difference to the move or shift function?

jeronij · « **Reply #50 on:** April 18, 2009, 07:31:20 AM »

Cogeo, the parameters for every mat are set the way they originally were. No changes at all after the first transparency applicattion. I though I could simple remove the existing transparency settings, and then apply the tool again, but it does not seem to work either

I can send you the file, but it is a big piece, around 1.4MB compressed... <-- sorry, I missed what you meant with :"Recognising the transparent state now depends on the setting for the Depth Func" .... now I got it, and it worked fine

About what I mean about centering, give me some time to try to explain better

cogeo · « **Reply #51 on:** April 18, 2009, 07:35:20 AM »

Quote from: jeronij on April 18, 2009, 07:31:20 AM

I can send you the file, but it is a big piece, around 1.4MB compressed...

No prob

jeronij · « **Reply #52 on:** April 18, 2009, 08:34:28 AM »

Finally I got the info about "centering props"

.. thanks to our living wiki, Tage

http://sc4devotion.com/forums/index.php?topic=4093.0

See specially Tage's post:
http://sc4devotion.com/forums/index.php?topic=4093.msg128642#msg128642

Saying "centering" is perhaps not the most appropriated word

...

Btw, perhaps you dindt see my edit to my previous post

sithlrd98 · « **Reply #53 on:** April 18, 2009, 12:13:38 PM »

Looks like I'm not the only one fascinated by Tages post in that thread..... I have no suggestions on how to implement centering or moving props/models , although in a perfect world, it would be awesome to have said model/prop open on a grid, and manually move the model to the desired location and then have the program do all the math!(Of course , its not a perfect world and your app is still very amazing!)

Jayson

buddybud · « **Reply #54 on:** April 18, 2009, 08:42:09 PM »

Quote from: cogeo on April 18, 2009, 05:04:41 AM

@buddybud: I'm considering such operations too. For 20-Z/R models this is not possible though, because of the missing back faces. But it is possible to perform another kind of operation (let's call it "Reorientate"), namely renumbering the instance IDs (for example 0x-----400 would become 0x-----410, 0x-----410 would become 0x-----420 and so on). This way it is possible to effectively "rotate" such a model by multiples of 90°. But for 1-Z/R a full rotation (or flipping, or mirroring is possible). For 90°-multiple rotations using trig functions is not even required, and performing simple coordinates changes is the prefered way (for such rotations the sin and cos functions are always 0, 1, or -1). For example, rotating a model by 90° clockwise means just setting x = y and y = -x. Do you really need rotations that are not 90°-multiples? I can only consider 45° for network models, though I really doubt if diagonal models are just orthogonal models rotated by 45°, some adjustments (esp width) are still needed, I think. Also I'm not sure about textures and triangles, shouldn't just moving the vertices be enough?

cogeo...thanx for the repy, i mentioned network models because unlike bat models they use back faces. When flipping them or rotating them the textures dissappear unless you correctly flip the triangles....for example this... 1 0 4 would become this 4 0 1. etc. This can be done alternatively with altering the uv settings for the model directly instead. As you mentioned this would not apply to bat models. And ya it is all simple process's but it would be great to automate.

edit i helped and shared this process with BlueLIghteing and he might be able to describe it better then i do but he also employed it.

great tool either way and it has a home in my toolbox

Bud

RippleJet · « **Reply #55 on:** April 19, 2009, 07:00:04 AM »

Due to RL commitments, I only now found this excellent development, Cogeo!

Regarding centering a model...
if you want to automate it, you only have the vertices of the LOD to go after.

Find the maximum vertices of each view in zoom 5, and determine the size of the model:

X₁	(west extension)	=	-1	×	[Maximum X vertex in view 2]
X₂	(east extension)	=	+1	×	[Maximum X vertex in view 0]
Z₁	(north extension)	=	-1	×	[Maximum X vertex in view 1]
Z₂	(south extension)	=	+1	×	[Maximum X vertex in view 3]

The centre point is the average of these extensions.
If the model is centered these should be close to 0:

X_C	=	(X₁ + X₂)/2
Z_C	=	(Z₁ + Z₂)/2

Ideally, if the LOD (at zoom 5) is a custom one, you'd use the maximum X coordinates for the model's zoom 5, but only those vertices having a minimum coordinate value for Y. Normally this would be Y=0, but allowance and tolerance needs to be given for models that have not been rendered at ground level.

Take a look at e.g. SimGoober's Peach Water Tower below:

This is the south (0) view.
Among all vertices having Y=0, the largest X value found is 6.40.
Higher up (betwen 27.4 and 50.4 m above ground) you can find higher X values though.

Provided that the LOD is not a simple box at zoom 5, you'd get buildings having bay windows and other extensions centered correctly this way.

If these values for the model's extension were automatically entered into the XML file as well, you would also get the occupant size set correctly. Based on the occupant size you'd get a smaller footprint in LE (which would allow bay windows to overhang the sidewalk), as well as a correctly sized building foundation (unless a custom foundation has been made).

cogeo · « **Reply #56 on:** April 20, 2009, 05:47:30 PM »

@buddybud: I understand that this might be needed for flipping/mirroring the model (as it inverts the drawing order of triangles, effectively making them "backfaces"), but is it needed for rotating models too? I doubt so. And yes, I need a more detailed description, I have never tried editing these ones.

@sithlrd98: Making this isn't simple, it requires implementing another major feature, ie displaying the model. Even if this is finally done, I'm not sure if the library allows selecting the model. Take a look in both the reader's and DatGen's S3D View panes, they are identical aren't they? This is beacuse they both use the same library. And none allows selecting anything in the preview pane. And moving the model manually (dragging?) isn't actaully accurate, ie it would be almost centered, but not "mathematically". This is waht we are actually trying to define here (see also the reply to RippleJet below). Not to mention that the program has a different philosophy, ie select the model(s) and apply an operation in "batch mode" - unlike the reader, which works on a per-object basis. Btw do you think this operation should be allowed to be applied to more than one (selected) models? It's something quite rare, I think, and somewhat risky to my opinion.

@RippleJet: This is basically the algorithm I had proposed above, based on the X and Y (Z in reader) coordinates' min and max values, but only examining the vertices at ground (or lowest) level, ie the base. The problem is that it doesn't cover all cases. As an example, take a look at my last upload, the Rural Rail Stations Pack. The small station (IIDs 0x0004####) has a sort of pavement at the front (all "ground-level" vertices are at Z=0.05, a suggestion by jestarr to eliminate the "jaggies" - but a "clever" algorithm would detect this anyway). As a result, the algorithm would not regard it as "centered", as this causes the model to be not symmetrical. Any object protruding off near the base can cause the algorithm to work not as intented. Don't want to avoid doing it, just trying to find a good solution, which I'm afraid is rather not possible.

Moving the model is really easy to implement. It's basically very similar to scaling the model, as they both operate on the vertices alone. The only differences are the parameters dialog, and the modifications applied. But everyhting else (like applying the operation to the selected models, changing vertex coordinates only etc) is identical. That is the code is largely a copy-and-paste (plus some modifications) of the scaling operation. Consequently, this will be the first to be implemented after V1.00 is released. The other ones are more complicated, not so much actually, but quite different, and thus need more work.

sithlrd98 · « **Reply #57 on:** April 20, 2009, 06:33:15 PM »

Quote from: cogeo on April 20, 2009, 05:47:30 PM

@sithlrd98: Making this isn't simple, it requires implementing another major feature, ie displaying the model. Even if this is finally done, I'm not sure if the library allows selecting the model. Take a look in both the reader's and DatGen's S3D View panes, they are identical aren't they? This is beacuse they both use the same library. And none allows selecting anything in the preview pane. And moving the model manually (dragging?) isn't actaully accurate, ie it would be almost centered, but not "mathematically". This is waht we are actually trying to define here (see also the reply to RippleJet below). Not to mention that the program has a different philosophy, ie select the model(s) and apply an operation in "batch mode" - unlike the reader, which works on a per-object basis. Btw do you think this operation should be allowed to be applied to more than one (selected) models? It's something quite rare, I think, and somewhat risky to my opinion.

Quote from: cogeo on April 20, 2009, 05:47:30 PM

Moving the model is really easy to implement. It's basically very similar to scaling the model, as they both operate on the vertices alone. The only differences are the parameters dialog, and the modifications applied. But everyhting else (like applying the operation to the selected models, changing vertex coordinates only etc) is identical. That is the code is largely a copy-and-paste (plus some modifications) of the scaling operation. Consequently, this will be the first to be implemented after V1.00 is released. The other ones are more complicated, not so much actually, but quite different, and thus need more work.

I hope I did not offend you!

I'm sure that it is very difficult to even create what you already have! If it wasn't , all of us could do it

My question was purely innocent as I was curious , since you were able to "automate" scaling, that "moving" a model would be awesome! I have no real mod skills (or programming skills...last time I did was on a Tandy computer back in the 80's), so anything that can help me is very much appreciated! I can see that it would probably be very taxing to load up multiple models with many different vertices (correct term?) and , in a way , re-render to a precise location. I have no idea of the ins & outs of these matters , was just curious if it could be implemented. Again thanks for your hard work

I really meant no disrespect.
Jayson

null45 · « **Reply #58 on:** April 27, 2009, 10:02:33 PM »

Quote from: cogeo

Take a look in both the reader's and DatGen's S3D View panes, they are identical aren't they? This is beacuse they both use the same library.

DatGen is a .NET program it's sd3 viewer is a separate implementation independent from the reader's version.

The s3d.dll source code is not included with the reader's source, that makes me wonder who made that dll.

Diggis · « **Reply #59 on:** April 28, 2009, 02:51:21 AM »

Cogeo,

I've had a quick play with the transparency settings and can confirm what Jeronij found, that when you change the transparency you can no longer edit it. I'll have a further play and see if that applys to doing anything, or whether it is just the transparency.

Menu

Author Topic: SC4 Model Tweaker Development/Support thread (Read 80039 times)