paramecij

- .max is the native format 3D studio max uses (use this when working with 3dsmax) - .max file is sort of an description of how max builds the scene, not a traditional 3d format like .3ds or .obj that contain pure vertex,animation, etc data.That's why it's almost impossible to import .max files into other programs (like for example you can't import .max into UU3d, ..but you can export UU3d from max ) -- autodesk now encourages the use of FBX format for transportation across different apps - There is a plug-in for 3dsmax so you can export/import in UU3D format, which will come real useful when things don't work the regular way or for a nice max <-> uu3d <-> other-formats workflow

I'm a programmer so my biggest grudge with LE2 is that it comes with too few models.. You can't even make a SINGLE decent game from those models!! .. LOL What I would like best, is for LE3D a system where you could define a bunch of .xml files and call engine::meakArt() on them and be done with the whole asset production altogether, either that or maybe a partnership with dex-soft and arteria3d so there are more models to choose from.. Who wants to watch a bunch of blender tutorials and then spend time making a high poly version for normal baking while also learning photography for better textures..all this time spent just for a fancy crate (that has been done million times before) instead of solid color cube - yeah, but which could be fully interactive and motion controlled by now, doing a funny dance I think game engines are meant for programmers, and tools are meant for artists to produce art in a suitable format for the engine to use. ..And recreational drugs are for fancy game designers to abuse

Wait, I don't get it. You mean it takes a minute for finding a path.. or what?

Maybe i'm using it wrong, but I can't see how far "off" i'm regarding scale. I can much better gauge this inside the editor (with grid or other objects to compare with) ... using AABB, one can easily know the height off the model and calculate a precise how far "off" scale factor from that. For me, the only useful thing in ModelViewer is the models hierarchy & properties tree-view. That's why I made my own, so I can also check LODs conveniently, and input custom frame ranges to check if animations loop correctly, etc.

I agree there should be more functionality packed into the ModelViewer, but instead of waiting and hoping for LE3, you could write your own ModelViewer - it's a simple one day exercise. You can use the models AABB to calculate how far to move the camera, in making a simple 'Fit into view' function.

Have you finished this one, or are you still searching/recording? .. it dawned on me that I got access to a sound studio and can use it for free, while I know nothing about sound production, I have a friend who is a real boy wonder in this field, he can do recording. mastering, post-production and is also very good at composing all kinds of music, can sing and is a good speaker.. but best of all, he's a nice person (like me ) and can be swayed for the 'cause' with some nice words and a couple of Heinekens. If you don't need many different voices (as finding other willing (free) actors who speak English well enough might be a problem) or if you need some tweaking and clean-up on your own recordings, or some custom BG music and loops we can work something out. This offer stands to anyone interested.

What about setting entity keys that are readable in code? (using LoadModel() no LoadScene() ) Would something like this work?: require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) selt.object:SetKey( "Type", "weapon" ) // or self.model or self.super ?? .. when do you use what exactly ? end

Even better then! (guess their page is a bit misleading, it only mentions .dae export under pro features)

Try exporting from sketchup as google earth .kmz file, then rename the .kmz to .zip. Inside you should find a collada file which you should be able to import in blender.

Hmm, I always avoided Qt and didn't even bother to look into it, because I suspected it would be bloated, slow and not a pleasure to work with. Seems I've been wrong on all accounts on this one. But I've settled on using AntTweakBar now,for all my opengl/LE testing and experimentation needs - it works like a charm and doesn't get in my way, also there's no learning curve, installation or integration, you can just start using it right away. But I'll definitely look into Qt the next time I need a full blown GUI system! So please post more of your 'findings' on this one

You can easily re-create the scaled physics bodies at run time in code, not really real-time with lots of objects, but at least you can do it at load time. (and avoid having multiple files for same model). That's how I currently do it. But it seems to me that the physics shape doesn't need to scale -if you only want to scale your whole world uniformly (all objects by the same amount), you can do so independently of physics if you also scale the position of the objects, after updating physics.. not sure how feasible this would be in LE, maybe adjusting position in UpdateMatrix callback, or parenting the meshes to world origin pivot and scaling that after physics could do the trick, but probably too many problems (octree, culling, lods, terrain, vegetation, lightning, ..)? .. just a quick thought while reading Flexman's spoiler

hm,I would try one of these: - check entities material - MeshName() (haven't used this one before, but i guess you would have to name your vegetation meshes properly before converting to gmf) - ModelName() - GetEntityKey() (and add keys to all vegetation models before hand, by arbuz exporter, code, or some other means) just some quick ideas from the top of my head, maybe somebody knows a better more direct way

It sounds about right (for the amount of force part).. but you also need to consider direction when adding force to body.. use a normalized vector to specify direction and then multiply it with the force scalar... but don't be surprised if it doesn't look right, game physics often don't look good if based on real world values

Good work! It seems you get the most bang out of your buck if you use bmax with this engine.. btw, how is that crosshair image working for you?, i've since made 64 of them, so let me know if you need a better one

Well thanks for spoiling that discovery for me as I just got UU3D too .. How are sketchup models turning out for you? I know some people here said that sketchup can produce some bad mesh topology, but from my very limited time with it, I didn't see any of it..

I understood that you aren't making anything MMO, the 'attempt an MMORPG' was more of a joke.. sorry for my badly put together reply - i'm not a native english speaker. Anyway I see that you're on the right track with your thinking, so all I can say more now is good luck with your project and hopes that you don't give up quickly!

Hacking together something playable isn't hard, but making a complete and polished game is nearly impossible (even the "pros" can't seem do this right most of the time). So I wouldn't start on any game just yet, .. Familiarize yourself with the engine first, load up the default spinning cube example in c, then modify and add to it. Go over the tutorials Josh made, write as much of short and simple spinning cube type programs as you can. Then when you feel confident enough with the engine, you can attempt throwing together a very simplistic game, doesn't matter what kind, it can be totally silly and pointless, the main thing is that you learn something from doing it, so make sure there are some unknowns for you to tackle,.. and once you tackle them you don't have to finish the game, just repeat the process and start another. (time spent polishing it, is time better spent watching some blender tutorials). You need to get yourself up to speed to gamedev, then you need to get good if you wan't to make a real multi-player rpg, And writing (and rewriting) lots off small programs or games is just like doing push-ups in a gym, each day you can do one more, and when you reach a fitness level where you can do infinite push-ups you know you can attempt an MMOPRG

The detail is even better in the originals. I have bump and spec maps for some of them already, while I'll make the rest if I decide to release or use them in my projects.. but I still haven't found a good method to make normal maps for grass textures, while rocks l found like pretty much any normal map you can generate for them I've made all of them in as high a resolution I could, as I optimize my game textures on a per project basis anyway, so it makes sense for me to keep the originals in a high resolution lossless format, I can use them in future cg/video game projects or if I end up selling them... I thought about starting my own free texture site (sponsored by donations) but there's already too many off them and I have too many other project right now to manage it. Also thought about joining/contributing to one of said sites but have't found one i'd really like... So an ideal solution for me I think would be if I could just ftp them somewhere as I make or update them, they'd be free to use in non commercial work, but there'd be an appreciation package one could buy for like 5$, 10$ or 20$ and get an thankyou.pdf if he got enough stuff and felt like it's worth something to him. But for commercial work you could buy an affordable license and do your own derivative work and sell it if you wished (some sites don't allow this, you can't take base human mesh and make a fully realized game character and sell it).. It's not that I want money, but I could really do with a new lens for my camera (all I have is a standard fixed 50mm and wide-angle 10-20mm lens for 3 years now) or maybe LE source

So I needed some textures and I set out to make them as I enjoy making textures (some like fishing, I like making textures) .. but I may have gone overboard and now I have a TON of them... (it was a stressful period ... Here's a small collection of my different types of textures, if you'd be kind enough to check them out and tel me what you think. (they are downsized - originals are mostly 2048x2048 or larger PNG/TGA files) Here are a couple of ground textures (you can use these if you like them) from my vegetation collection, (i have more than 200 like these - with masks): tree bark and wood rings sample (also have lots of these) I also have a LARGE collection of stuff like metal, wood, concrete, asphalt, doors, facades, manholes, vents, etc.. .. as I said I have hundreds of high res textures like these ones , but i'm not sure what to do with them.. are they even any good?

The ray hits the animated mesh accurately as it's currently displayed, regardles of it's collision (physics) shape.. raycasts work only on renderable meshes, while physics collisions work with static shapes only..

I think most people here use 1 unit = 1 meter .. it's not hardcoded anywhere (but you'd want to change the default cull and lod ranges) so you could scale everything else to dexsoft scale I think.. but since i'm from europe I've never used anything other than meters so this scale seems natural to me

As I said, It has been done before (search the forums), and even LE uses this method for it's terrain texturing.. but writing a shader is not that hard.. you can paint mesh vertices with colors to control blending, each channel of this vertex color being used as a 0-255 alpha value, or you can paint a texture with this information and map this whole texture onto your mesh via a second UV channel or by manualy calculating uvs (easy if you have a grid like mesh) .. you can use one texture as base that tiles over the whole mesh, then you can use RGBA channels to blend 4 additional textures on top of the base one - a total of 5 different terrain types.. since you can have a map with tunnels and such (i think), mapping a single texture onto the mesh may not be trivial so I suggest using vertex colors on your mesh.. arbitrary number of terrain types is not impossible, you don't really blend between more than 3 types (usually just 2) at one time.. so you could break the mesh up into multiple zones that uses different texture sets ... or you could again use texture atlases, using R and G channels to specify textue1 and texture2 IDs, B channel to control the blending, this way you could have arbitrary number of 'textures' (well one or two really, but you could use morre terrain types to blend with)

Sure there's a more modern approach, I think Aily created and posted something on the forum you should check out.. what is best depends on what you want.. Maybe I'm way off here, but when you said small isometric rpg with map made from cubes, I was thinking maps looking along the lines of this (quick google search): and suggested to build a texture like this: (notice how the transition between sand and pebble is made (tile 14), you just draw a simple mask around a layer - which you can reuse on other types and have all transitions done in minutes) ..since you have a way of generating/placing cubes (an editor?), and you may already have some type or material or some other property you could set a tile ID to them, then when you generate your mesh it would be trivial to calculate uvs from the cubes ground type.. not much to implement really, and manual painting will took less time then debugging any other solution .. but the real benefit is that you would have your terrain rendered in one draw call using just one texture, with traditional terrain splatting method you'd have 5 types (..yeah you can do more but it's not as elegant) ..I can get more in depth with the method like in the article you linked to.. it would help if I could see how you imagined your levels to look like

I think the easiest way would be to make a texture atlas (big texture that contains smaller textures), and when you generate your mesh, just assign appropriate uv's to each quad (1quad = 1 cell from the texture atlas) .. let's say you make your big texture 2048x2048 and use 256x256 for ground texture tiles, this allows for 64 different textures, enough resolution for isometric view i think and enough room for you to make all the additional transition tiles you need.. and it's good for performance also

What kind of mesh are you generating?