Using Blender (open source modeling program) for content creation.

[vortext]

The 'orthographic scale to fit all the coordinates in the camera view' is essential to framing the views and determining the end UV coordinates per sub mesh so that will be rather handy. In the BAT scripts this is then modularised into multiples of 256 for zoom 5, and smallest power of 2 to fit for the other zooms for the rendertexture sizes.

Regarding the textures sizes, played around a bit this morning with different LOD sizes and I noticed gmax will actually produce smaller textures if the LOD is equally smaller as well. For instance an 8x8x8 cube results in a 128x128 px texture for zoom 5. Likewise a 2x2x2 cube renders to a 32x32 px texure for zoom 5 (and zoom 1 to a whopping 4x4 px  ).

Consequently it seems the orthographic scale can be better thought of as a orthographic constant. That is to say, if I calculate the orthographic scale for the 8x8x8 cube following the procedure followed here, it results in ~23.5. Plugging that into Blender, however, things seemed off. Setting the gmax render as the background image for the camera it quite clearly is not correct, as shown below.




Now taking the orthographic scale found for the 16x16x16 cube (~36.5), dividing it by 2 and applying the result as orthographic scale for the 8x8x8 cube and things look a lot better.



The jagged edges from the gmax render are still visible, however, it's a much better fit overall.

So it seems the render procedure for Blender will need to utilize a 'constant', pre-determined orthographic scale which is halved / doubled depending on whether the orthographic scale for the whole LOD is smaller or bigger than said constant. And of course the output dimensions need to be set accordingly as well.

Also, on the subject of the smallest possible model. I've exported a LOD measuring 0.25 x 0.25 x 0.25 meters. Gmax renders without a problem, sc4pim shows the model just fine as well and sets the correct occupant size. All that said the model just won't show up ingame. Not as a building, nor as a prop, and not even when zooming in all the way with the sizeoff command. It appears there is somekind of size limit inherent to the game graphics rendering engine itself?


Thanks Matt for the info. Regarding the 8 lights all having the same coordinates, it would make sense if these were global illuminating lights. For instance in Blender the actual position of the sun doesn't matter, only the angle at which parallel light rays are cast. And I imagine this is pretty much the same in all 3d modelling software. Then again why would there be 8 global lights in a scene.. 

[rivit]

@vortext - that is a very useful advance, and yes the zoom 5 sizing is dependent on the size of the LOD. The n by 256 is when the LOD is too big to fit in one texture. Remember to keep a small constant margin all round (say 4 or 8 pixels) so that nothing bleeds past the texture edges when rendering and it will also lead to cleaner FSH.

In work going on in the background a milestone - Matt has sucessfully loaded the reference building into gmax, and (albeit sans textures) into Blender - but it's version 2.79. We have not been able to get it into 2.80 as the .3ds functionality isn't there. FBX fails in both.

TODO: Decide for sure which version of Blender we go forward with - 2.79 is stable, 2.80 a Beta. From a development perspective using the latest stable version is to be favoured over an incomplete Beta.  Is there anything so far other than "look and feel" that isn't in 2.79 that we have identified we need? If not I vote to use 2.79 first as that will maximise our chances of success for now. 

[tomvsotis]

@vortext - that is a very useful advance, and yes the zoom 5 sizing is dependent on the size of the LOD. The n by 256 is when the LOD is too big to fit in one texture. Remember to keep a small constant margin all round (say 4 or 8 pixels) so that nothing bleeds past the texture edges when rendering and it will also lead to cleaner FSH.

In work going on in the background a milestone - Matt has sucessfully loaded the reference building into gmax, and (albeit sans textures) into Blender - but it's version 2.79. We have not been able to get it into 2.80 as the .3ds functionality isn't there. FBX fails in both.

Yeah, the textures are the hard bit. Exporting meshes FROM Blender to gmax/3ds Max is pretty straightforward via FBX, but textures/UVs don't play nice.

TODO: Decide for sure which version of Blender we go forward with - 2.79 is stable, 2.80 a Beta. From a development perspective using the latest stable version is to be favoured over an incomplete Beta.  Is there anything so far other than "look and feel" that isn't in 2.79 that we have identified we need? If not I vote to use 2.79 first as that will maximise our chances of success for now.

I think you're right that 2.79 is the better choice for now. The interface can be... a bit confusing, but it's fine once you get the hang of it. 2.80 is meant to be out of beta in "early 2019", fwiw — but when that happens, i don't think there should be anything to prevent us porting our scripts etc forward to 2.80.

[vortext]

Agreed developing against a stable release is more sensible, and the lack of 3ds support in 2.8 is another reason to do so.

As for potentially porting scripts forward, from what I understand there're some fundamental changes internally as to how a scene is structured in 2.8. It used to be organized in layers, going forward however so-called collections will take their place. This change also directly affects the python api concerning how the scene is accessed. Something to keep in mind I suppose.

[tomvsotis]

Agreed developing against a stable release is more sensible, and the lack of 3ds support in 2.8 is another reason to do so.

As for potentially porting scripts forward, from what I understand there're some fundamental changes internally as to how a scene is structured in 2.8. It used to be organized in layers, going forward however so-called collections will take their place. This change also directly affects the python api concerning how the scene is accessed. Something to keep in mind I suppose.

Yeah. Fwiw, what they're calling "collections" are actual layers in the sense that anyone who's used Photoshop and a whole lot of other programs would recognize. 2.79 "layers" are a pretty poor approximation of layer functionality; you're limited to 10 of them, you can't name them, etc. All of which is to say, i think 2.80 layer functionality will, if anything, make things easier; but if we stick to 10 or less layers in our 2.79 scripts, we should (in theory, anyway) be able to port them straight over to 2.80.

[rivit]

Well I was going to summarise how we were doing today, but I've been staring at a code editor for too many days in a row, so got taken by the bug that is trying out a new program called Blender. Because Matt had managed to get it to import the Reference BAT, I wanted to see for myself what it was like. Keep in mind I'm no 3D Editor hero - I have only played with gmax and 3dsmax on occasion.

Well I have to say, I'm not going to get those several hours back in a hurry. My first impression was that of a GUI where everything you need is hidden, nothing you need frequently stays where you found it and that it needs the dexterity of an octopus to wrangle. It is written with a workflow I really don't understand intuitively (definitely not Windows) - probably really good to prototype in, but for exact work may well be extremely tedious - jury out on that. Someone who actually knows how to turn primitives into something like a 3dModel will be better placed to judge. That simple things like input fields don't work as you expect is disconcerting but will presumably grow on you.

My overall impression was like driving a mid-class vehicle with some very powerful modifications requiring a zillion settings to prevent yourself running off the road. Don't get me wrong, this can probably do what we need it to but so far for me its going to be like a relative you may only tolerate to see when you have to. Too harsh?  Maybe. It is a first impression. Even after 1000 bugfixes 2.79 still can get itself in a dither, or show faulty imagery. And why, oh why, is there no prominent UNDO button?

Firstly the import of the 3ds model worked - with reservations. It brought everything in, but mangled the shrubbery badly. It brought in the Sun, Sky and 3 cameras - but none of them were meaningful - just empty entries. It brought in the LODs OK. Also a lot of other dummy entries. It did create some sort of material library - but didn't bring in the materials themselves or their labels. Even after editing materials I couldn't get any bitmap materials to work - but that's probably me. I did get some procedural ones to work.

So given that the Reference Model and its intricacies was all beyond me I thought I'd concentrate on the Renderer(s) - an interest of mine from a long way back. There are two, an internal renderer and the Cycles renderer which uses the GPU. The internal renderer seems to make a standard Sun and Sky (don't know where is standard and can't see any flexibility as yet, except for atmospheric effects which are cool), and renders simple things well. Color control was surprisingly primitive but then most things are done with textures. It may well do, if and when we can see what gets done with textures.

The Cycles renderer was, for me, a bit like playing with the code from a series of published scientific articles on rendering (of which I've read many) so I recognised most of this - it can do quite a few rather neat things, yet once again also can be fooled easily into incorrect renders. May be me again too here. Lots of settings to get right. Transparency was one place I got strange results. This is an infinitely configurable beast - so it too can do what's needed - just need a PhD to work out how.       

Image processing looks quite strong both compositing and fiddling - definitely PNG oriented, but may do some post processing for us for the variable night alphas. Its strongly supportive of animation, and it also has a Game engine mode for making moving things for games, which I didn't try out. There are many public domain addins (some of which may give us hints how to code things), and the best of them cost $$$ - no surprises there. Only tried one out - the dynamic Sun/Sky but didn't understand how to drive it or the results - will need to try this again.

Be interested to see what others make of Blender - I remain open-minded. No Monkeys were harmed in the making of this review.

Here the only lasting result of my playing today - Cycles renderer: metal,foam,velvet. Blender Orthographic Camera in the wrong place but Standard Sun/Sky.

[tomvsotis]

Well I was going to summarise how we were doing today, but I've been staring at a code editor for too many days in a row, so got taken by the bug that is trying out a new program called Blender. Because Matt had managed to get it to import the Reference BAT, I wanted to see for myself what it was like. Keep in mind I'm no 3D Editor hero - I have only played with gmax and 3dsmax on occasion.

Well I have to say, I'm not going to get those several hours back in a hurry. My first impression was that of a GUI where everything you need is hidden, nothing you need frequently stays where you found it and that it needs the dexterity of an octopus to wrangle. It is written with a workflow I really don't understand intuitively (definitely not Windows) - probably really good to prototype in, but for exact work may well be extremely tedious - jury out on that. Someone who actually knows how to turn primitives into something like a 3dModel will be better placed to judge. That simple things like input fields don't work as you expect is disconcerting but will presumably grow on you.

My overall impression was like driving a mid-class vehicle with some very powerful modifications requiring a zillion settings to prevent yourself running off the road. Don't get me wrong, this can probably do what we need it to but so far for me its going to be like a relative you may only tolerate to see when you have to. Too harsh?  Maybe. It is a first impression. Even after 1000 bugfixes 2.79 still can get itself in a dither, or show faulty imagery. And why, oh why, is there no prominent UNDO button?

Firstly the import of the 3ds model worked - with reservations. It brought everything in, but mangled the shrubbery badly. It brought in the Sun, Sky and 3 cameras - but none of them were meaningful - just empty entries. It brought in the LODs OK. Also a lot of other dummy entries. It did create some sort of material library - but didn't bring in the materials themselves or their labels. Even after editing materials I couldn't get any bitmap materials to work - but that's probably me. I did get some procedural ones to work.

So given that the Reference Model and its intricacies was all beyond me I thought I'd concentrate on the Renderer(s) - an interest of mine from a long way back. There are two, an internal renderer and the Cycles renderer which uses the GPU. The internal renderer seems to make a standard Sun and Sky (don't know where is standard and can't see any flexibility as yet, except for atmospheric effects which are cool), and renders simple things well. Color control was surprisingly primitive but then most things are done with textures. It may well do, if and when we can see what gets done with textures.

The Cycles renderer was, for me, a bit like playing with the code from a series of published scientific articles on rendering (of which I've read many) so I recognised most of this - it can do quite a few rather neat things, yet once again also can be fooled easily into incorrect renders. May be me again too here. Lots of settings to get right. Transparency was one place I got strange results. This is an infinitely configurable beast - so it too can do what's needed - just need a PhD to work out how.       

Image processing looks quite strong both compositing and fiddling - definitely PNG oriented, but may do some post processing for us for the variable night alphas. Its strongly supportive of animation, and it also has a Game engine mode for making moving things for games, which I didn't try out. There are many public domain addins (some of which may give us hints how to code things), and the best of them cost $$$ - no surprises there. Only tried one out - the dynamic Sun/Sky but didn't understand how to drive it or the results - will need to try this again.

Be interested to see what others make of Blender - I remain open-minded. No Monkeys were harmed in the making of this review.

Here the only lasting result of my playing today - Cycles renderer: metal,foam,velvet. Blender Orthographic Camera in the wrong place but Standard Sun/Sky.

LOL. I have never quite understood why people hate Blender, but this is ... a pretty detailed explanation. 

A couple of points:

Cycles is def the renderer we want to use. Blender's internal renderer is antiquated and lacks support for a far few modern features. 2.80 includes a new renderer called Eevee, which is basically interchangeable w Cycles — materials created for the former work in the latter, and vice versa — and is easier to use, so that may be our longer-term answer, but for now, I think we stick w Cycles in 2.79.

The dynamic sun/sky is fun to play with, but just using a basic HDR also gives pretty acceptable results. And we'll presumably be placing lights etc via script?

2.80 fixes a lot of the UI-related quirks that 2.79 users have come to know and, ahem, love. So again, I think that's prob our best long-term option once it's out of beta. But 2.79 is OK (honestly!) once you get used to it. Here's my latest project, all modeled in 2.80: you can get some pretty decent results, and I personally find it WAY less tedious than 3ds Max (although, of course, that's prob a case of familiarity with one workflow over another):

[tomvsotis]

Hey all, how would we feel about setting up a Discord server for this project? I've taken the liberty of snaffling the Bat4Blender name; if you guys are keen, lemme know and I'll send you the link.

[tomvsotis]

A bit of progress!

I've imported Matt's model into Blender 2.79 as a .3ds. This seems to be the only import method that's working at the moment — FBX throws me a heap of errors, annoyingly. I'm going to have a play around with Matt's model in Max to see if I can simplify it a bit, and see if that helps (or, failing that, to at least identify the sticking points.)

Unfortunately, as discussed here before, using .3ds as an import/export format seems to break materials. There doesn't seem to be any way around this except manually recreating materials; the progress here is that I've recreated a couple of Matt's materials in Cycles, and they look basically the same as they do in Max. Hurrah!





(Also worth noting: you can see from the first pic that the UVs generated by Max's UVW Map modifier look like a dog's breakfast in Blender. This is a problem I came up against trying to export from Blender to gmax via the .3ds format, too.)

[vortext]

he yeah Ron all those points you mention regarding the unintuitive UI and elaborate nature of the workflow is exaclty why the re-design of 2.8 is such a big deal. That, in addition to the real-time renderer and along with the aforementioned restructuring of things under the hood in fact makes it quite a different piece of software compared to previous versions, and some argue it should've been called Blender 3.0 to demarcate this.

Nice progress Tom! 

Can't help with the max materials as I don't have max to begin with, which in fact is one the motivating forces behind all this (and yes, acquiring a student license for 3dsmax would be a lot easier than trying to create an viable alternative to it but where's the fun in that!  )

As for a discord server, I suppose another channel of communication doesn't hurt. Just as an FYI there actually is a sc4d discord server, which I happen to be the owner of (shameless plug   ) and another channel w member roles is easily created as well. 

On my end I ported the addon to v2.79 and barring any unforseen obstacles I reckon a working prototype should be ready somewhere by the end of next week, which as far as I see it needs to be able to do 2 things (well 3, really);

- able to render all zooms & rotations
- able to add/delete/export LOD as 3ds

Lots of caveats and remarks to be had here. For starters the first point implies the ability to rotate the sun object as well. I assume (dangerous .. ) this will work pretty much along the same lines as rotating the camera object, however, I have not yet implemented this. So, fingers crossed there.

Second of all I fully expect the alligment of views will need to be tweaked multiple times as we work through various test cases, i.e. do not expect perfect allignment. No promises on correct output dimensions either, and slice 'n dicing may need to take place outside of Blender to begin with anyway. Same goes for converting png to fsh and assignment of tgi, though GoFsh can do a lot of heavy lifting there.

As for the yet unmentioned 3rd point; the addon should be able to be distributed and installed on other machines. Spend yesterday evening working out the kinks on that end and while the result is just a simple .zip file, there's a (un)surprising amount of things which can go wrong .. 

Once the addon can do those 3 things more stuff can be added to it like; preview renders, adding/deleting sun & camera from the scene, custom LODs etc. And while on the subject of LODs, what is the purpose of the LOD3, LOD4 & LOD5 as seen in gmax? I suppose these correspond to the zoomlevels, but I don't quite get what their purpose is? Is there a different geometry to them per zoom, and if so how does that benefit mapping the rendered image? 

[mattb325]

Nice work you three 

I figured that the way I model (super-quick and tailored for SC4, but not 'proper' in terms of 3d modelling) might cause some issues. Tom, the textures are looking good...I also got the model to export/import as an .obj file. That process also created a texture library; unfortunately my blender knowledge is insufficient to do anything else with that other than note that it occurred! 

The LOD3/4/5 are all the same size in gmax (they are literally cloned) but each represents the zoom size of the pasted image in game. In that regard, I guess you'll also need to replicate thumbnail cameras and z1 and 2 unless that is just going to be done by a calculation....

[tomvsotis]

Tom, the textures are looking good...I also got the model to export/import as an .obj file. That process also created a texture library; unfortunately my blender knowledge is insufficient to do anything else with that other than note that it occurred! 

Hmmm, just had a look — same deal as the .3ds, I'm afraid, in that they're all just blank materials. It seems that either way, we need to recreate the materials and (possibly) some of the UVs. I think it'd also be the same w FBX. This is why I came to the conclusion for my models that it was gonna be easiest to just texture them in Max — all of the various inter-program export formats seem to have trouble w materials and textures :-/

[rivit]

Hi all - nice work everyone,

seems like a day for a number of reveals and progress milestones. I have finally completed the Hatrack for the GUI and can present that here. Its working code inasmuch as when you hit a button it tells you what its going to do, but doesn't actually have the backing code yet. That's where the stuff the vortex has been producing will fit straight in. It takes the form of an exe right in this folder https://1drv.ms/f/s!AphvaLJG-tShg4waHjo9pVt58Fadqw so feel free to download it and punch it around a bit and think about whether I have everything covered. If it survives then it can be built into a GUI for the plugin. Ive also started on the downstream processing thinking.

The other big thing is that I've managed to get all of the Camera and Light data out of the rig. Oddly enough just loading the rig into gmax as if it was a model was the key at getting to this data.  I am pleased to see its largely consistent with what I had derived by measuring bitmaps so many years ago. Very close but subtly different.

All of this data is also to be found in the docs folder named above as a text file and as an .xlsx file.

There are in fact 7 cameras defined altogether, but in our implementation we really only need one and change its settings as we need to. I also have the coordinates of the target for the cameras.

As far as lights go I was very surprised to see there  were 10 lights defined - in addition to the prime light a series of fill lights play the roll of smoothing out the light all around a model in a studio-like lighting setup. They also play a role in getting a fairly straight light response to texture color.  Now in principle we will only be using a Sun - corresponding to the primary light but we have the data on the colors as well, and so some clues as to enhance the result.  see 2nd pic

This data has thrown up an anomaly with BAT4Max - it appears the Sun here is not quite at the same vector as the gmax rig - its lightly lower so shadows cast in BAT4Max should be longer and north of those in gmax. Also the target (in previews at least)  is taken offset from the centre of the LOD, rather than in gmax a fixed offset from the ground which presumably slightly changes the positioning of the render i.e. where it ends up on the bitmap.

I'm looking forward now to using those bits already made and will take some time to think through the main processing - in particular the slice and uv mapping of the LODs. I'm also going to rtfm some of the bits I obviously don't get just by fiddling with Blender.

Ron
 

[Jasoncw]

It's great seeing progress on this project.

The GUI looks good in general (and I love seeing that model name and group id area) but there is an issue I see.

There are buttons for setting Day, MaxisNite, and DarkNite. These change the light settings and also the rendering settings.

Then there are two preview buttons, and pressing one of the buttons changes the rendering settings and starts a preview. The problem with this is that it prevents the user from changing the rendering settings themselves. If you edited the rendering settings, you wouldn't be able to do preview renders, because pressing the preview button would change the rendering settings back. So if you wanted to include a button to make draft rendering settings, you would want to make those buttons separate from the preview render button.

In BAT4Max there are also buttons for making the night brighter or darker, and what those do is switch between MaxisNite and DarkNite without affecting (overwriting) rendering settings which the user might have customized. I've personally never used these buttons, and just manually re-changed my custom rendering settings, but I don't know if other people used them.

The draft and final rendering settings would have been easy to implement in BAT4Max but iirc the purposeful choice was made to use one set of generally good settings, to make BATing as WYSIWYG as possible. And then for special cases, to encourage people to change the settings themselves. I personally agree with that decision (and the rendering settings in Cycles are more intuitive than Mental Ray's), but this is a different situation and so some presets like that might be useful.

[fantozzi]

Guys, this thread goes above my head. I just applaude to the sound of knowledge. 

I think the advantage of cycles render is it's free. One can switch from cpu to gpu rendering. It can make use of highly specialized hardware on 3D rendering - gaming cards. Especially cycles renders can benefit from nvida cards and those so called cuda cores created for 3D games. So you can speed up rendering by combine graphic cards instead of buying whole new pcs.

Disadvantage is: the whole project has to be loaded at once into graphic cards memory - means: the object and the texture, everything has to be present in the gpu memory. Cyckes doesn't support file swapping.

But on the other hand there is no limit in render quality. You just choose infinite render and when you like it you just stop rendering. You can stop rendering at any time without losing data. This is what I like about cycles render engine.

[Barroco Hispano]

Blender cycles and Evee is compatible with PBR materials so that will be very helpful 

[rivit]

Hi Jason and many thanks for taking a reviewers eye to the GUI proposal. I appreciate the feedback and I'll answer your valid point on the Previews in a slightly roundabout way.

The logic behind the Plugin Design is to minimise the code in general so the following principles are followed:

• Only change things in one place if you can
  
• Separate changes for environment (Sun,Sky) from other changes that affect the render (Camera, Viewport, Background colours, AA, Sampling, etc etc)
  
• Move the very simple Rig (Sun, Camera) when needed to new points of view, rather than have a massive set of things to choose from (and keep track of). It may yet prove necessary to add some fill lights but we'll see that when we try to emulate gmax/3dsmax renders.
  
• Don't touch anything that isn't defined as part of the Standard. e.g. don't ever touch extra objects, lights or settings/parameters in the scene that the user has set. In practice act as if these didn't exist/matter - its up to the user to see their effect doesn't ruin the result. In fact for night scenes I imagine these are critical to getting the desired result.
  
• If we find flaws down the track in this we can adapt/bend/change - but the principles above will still hold.
  

What I'm trying to avoid here is the repetition of code I see in the maxscripts to check and recheck state on the run instead of nailing that down before starting things. Since we aren't experts in Python we need to keep the code clear and simple to avoid burying ourselves. We have the advantage of a clean slate - we are not modifying existing code.

So I envision that there is a given State associated with Day, Maxis Night (we are not doing MN), and Dark Nite - this gets set up when you select that rig. Resetting the rig reinstates those settings at will; Rebuild Rig sets things up from scratch back to Day. These are insurance - you could just as easily select the Rig setting again. Previews and Export will set the check/set the Camera/Render parameters, then do their thing.

Draft Render (which I reintroduced to the design and which may not survive) is an anomolous (presumably much less fancy and hence FAST) state and so it should save the Standard state before and restore it at completion. The same sort of logic will be taken in the LODs, and the files management. Make and maintain standard state.

Now its still not at all clear what the "locked" Settings and Parameters for Environment and Render will be (and they will need some form of consensus), but I would hope to restrict these as much as possible. It will depend on what the art experts (like yourself) need to recreate the right look and feel of the result. But once set, thats our standard.

It should be easy to add/change things but difficult to break the standard.

[tomvsotis]

OK people, here is is: Matt's Engineering Dept, imported as an .OBJ, and rendered in Cycles. Ta-da!


i had to recreate all the materials, because the materials imported as part of the .OBJ were, er, interesting:


How/why this node group was created and how it reflects the Max materials are ... unclear, but it was easy enough to nuke them and re-apply Matt's textures. I created the glass material (which is reflecting the sun in the HDR i used) and the lights from scratch, with Cycles' Glass and Emission Shaders respectively.

But anyway, I'm happy with this! It looks good, the OBJ import has recreated the shrubs etc well, and the little details etc have rendered fine. Hurrah! We have a reference building in Blender!

[rivit]

Well done Tom - a huge step forward for sure!

[vortext]

Great work indeed, looks nice! 

Thanks for the info dump Ron regarding the camera & lights, usefull reading material. 

Meanwhile the gui is hooked up to the camera. Was a bit more work than anticipated due to having to register a set of variables with Blenders UI manager. Kinda makes sense though, and passing the same info along to other methods should be relative straightforward now. The addon is relocated to the Scene context menu btw, since v2.79 doesn't have an Output menu. And minor nitpick but it's a bit annoying Blender doesn't seem to have proper radio buttons (i.e. circular). . ah well.