#93661 - parrot_ - Thu Jul 20, 2006 2:56 pm
Right, I have some questions on 3D for the DS?
1. What would be the best, easy, free editor?
2. Any adivce on how to get started?
Could anyone help me with these? I'd be very grateful.
_________________
Squak! etc.
My Blog
#93666 - tciny - Thu Jul 20, 2006 3:54 pm
I think there's no such editor you're looking for. Basically, you have to program all the stuff you need yourself in C/C++
So the advice would be to lean C/C++ to a level where you feel that you're familiar with the language. Then look into OpenGL... when you're done with that, try to get into DS programming.
If you're interested I could recommend some books... mostly german tho :)
#93667 - Sausage Boy - Thu Jul 20, 2006 3:56 pm
I like Wings3D, though I hear Blender is better. It's just too damn complicated! I believe there are loaders for the md2 3d format, so anything that can export to that is good. You might end up needing to write your own exporter and loader though, when you make Real Cool Games.
_________________
"no offense, but this is the gayest game ever"
#93671 - clone dad - Thu Jul 20, 2006 4:27 pm
blender is actually quite easy. It just takes some time to get used to it.
_________________
I don't know anything.
#93682 - parrot_ - Thu Jul 20, 2006 5:02 pm
| tciny wrote: |
I think there's no such editor you're looking for. Basically, you have to program all the stuff you need yourself in C/C++
So the advice would be to lean C/C++ to a level where you feel that you're familiar with the language. Then look into OpenGL... when you're done with that, try to get into DS programming.
If you're interested I could recommend some books... mostly german tho :) |
I'm already in DS Programming. I'm just all tied up with 3D. Maybe I should stick with 2D?
_________________
Squak! etc.
My Blog
#93685 - Sausage Boy - Thu Jul 20, 2006 6:06 pm
| clone dad wrote: |
| blender is actually quite easy. It just takes some time to get used to it. |
Can you recommend a good tutorial to start with?
_________________
"no offense, but this is the gayest game ever"
#93689 - silent_code - Thu Jul 20, 2006 6:47 pm
| tciny wrote: |
I think there's no such editor you're looking for. Basically, you have to program all the stuff you need yourself in C/C++
So the advice would be to lean C/C++ to a level where you feel that you're familiar with the language. Then look into OpenGL... when you're done with that, try to get into DS programming.
If you're interested I could recommend some books... mostly german tho :) |
;) i think you got it wrong, he want's to know with which model editor (look at the other posts...) to work with. i can't imagine what other editor you might be thinking of ;p
personally i prefer cinema4d (i have version 6), but you'll have to buy it (though there is that free full version with a maximum render port size of 600x400 - shouldn't be a problem for nds ;D - i don't have any url, sorry).
then i export to .obj and depending on what i wan to do with the model i load it into ms3d (damn, another non free tool!) and export or modify it (or use the ms3d file with lith unwrap ;D - at least that's free - there is a newer version that is commercial, but it's got another name... i think unwrap3d or something).
you can write your own tools (exporters and stuff), but there are already some of them on the net. mostly for .md2 i think (someone said that before). maybe someone will make a ms3d im/exporter for display list models (or whatever), so everything will be simpler.
#93693 - josath - Thu Jul 20, 2006 7:09 pm
Personally, I want to be able to draw some simple object in a 3d app, export it and stick the model file in my data/ dir in my nds project folder.
and then write some code like:
| Code: |
main() {
init3D();
set3dViewport(...);
Object3D player = new Object3D(playerModel_bin);
player.x = player.y = player.z = ...
while(1) {
if(KEYS & KEY_LEFT)
player.x --;
if(KEYS & KEY_RIGHT)
player.x++;
...
update3DObjects();
WaitForVSync();
}
}
|
I don't want to have to fiddle with manually drawing triangles, or worry about what is a display list, GLmatrix, and so on.
Is there anything like this available? Does anyone plan on writing a easy to use 3d DS library for the 3d-impaired?
#93698 - tciny - Thu Jul 20, 2006 7:21 pm
I'm currently developing a 3d format for the DS. There'll be an exporter for Maya Win/OSX, as well as a viewer Win/OSX and the code to load and display the models on the DS... though it'll be a few weeks before the whole thing works smoothly as I'm currently moving and starting a new job :)
It'll allow you to save models with skeletal animation. You have one file for the model/rig and another one for the animation. That way you can save memory by using one walkcycle for all characters of the same type etc...
Right now the basic stuff like storing the model and the skeleton as well as displaying them is up and running, but I'm still looking into ways of converting and storing the textures etc.... I have to look into that stuff more before I continue as I'm not quite familiar with the texture format yet... but as soon as it gets interesting I'll open up a thread here.
#93700 - Sausage Boy - Thu Jul 20, 2006 8:35 pm
tciny, ask me if you want some info about textures. I did some research about them and exactly how they are referenced in display lists etc. I'd be happy to share my knowledge.
_________________
"no offense, but this is the gayest game ever"
#93718 - tciny - Thu Jul 20, 2006 9:44 pm
Hey, thanks a lot :)
So heres goes:
- What format does the DS store textures in internally? I'd like to prepare all the data so I don't have to do any conversions on the DS. Also, what texture format would you say is the fastest one in terms of drawing? (Are all textures paletted?)
- As I understand it main memory and texture memory are two seperate things? If so, how much texture memory is there?
I'm familiar with OpenGL, but this is my first bigger NDS app... so are there any things that I should be aware of as they're different?
#93727 - Sausage Boy - Thu Jul 20, 2006 10:23 pm
1.
http://dualis.1emulation.com/dsti.html#lcdioteximgparam
Look at TEXIMG_PARAM. That's the format you use in your display list. I'd just store a u32 with bits 16-31, and or it with the address when you load the texture.
As you can see in the data under, some textures are paletted, some are not. The compressed texture format is kinda wierd, don't worry about that for now. You'll just need to store data and palette, and the TEXIMG_PARAM.
Afaik, all textures are equally fast. The smaller ones would load faster, I presume. It's not really hard to support all texture formats.
2.
You can map the VRAM banks as texture mem. I'm not 100% sure how this works, you'll have to experiment.
I personally wouldn't use a lot of the DS's OpenGL implemention. Imho, it abstracts you away from the hardware, and makes it harder to do things that really are possible.
_________________
"no offense, but this is the gayest game ever"
#93795 - parrot_ - Fri Jul 21, 2006 9:03 am
| josath wrote: |
Personally, I want to be able to draw some simple object in a 3d app, export it and stick the model file in my data/ dir in my nds project folder.
and then write some code like:
| Code: |
main() {
init3D();
set3dViewport(...);
Object3D player = new Object3D(playerModel_bin);
player.x = player.y = player.z = ...
while(1) {
if(KEYS & KEY_LEFT)
player.x --;
if(KEYS & KEY_RIGHT)
player.x++;
...
update3DObjects();
WaitForVSync();
}
}
|
I don't want to have to fiddle with manually drawing triangles, or worry about what is a display list, GLmatrix, and so on.
Is there anything like this available? Does anyone plan on writing a easy to use 3d DS library for the 3d-impaired? |
That would rock. Could anyone with 3D experience on the DS do this? You'd be helping the 3D imparied a lot.
_________________
Squak! etc.
My Blog
#93835 - Sausage Boy - Fri Jul 21, 2006 4:19 pm
I'm up for the task if anyone's willing to join forces with me.
_________________
"no offense, but this is the gayest game ever"
#93836 - tciny - Fri Jul 21, 2006 4:39 pm
As I posted above, I'd be happy to contribute a model format (maya exporter, viewer and DS loader)...
#93837 - parrot_ - Fri Jul 21, 2006 4:41 pm
I'd be happy to outline the needed features
_________________
Squak! etc.
My Blog
#93838 - Sausage Boy - Fri Jul 21, 2006 4:42 pm
Will your plugin be compatible with Maya PLE? How hard would it be to convert it to be used with free programs such as Blender?
_________________
"no offense, but this is the gayest game ever"
#93839 - tciny - Fri Jul 21, 2006 4:46 pm
Unfortunately you can't convert Plug-Ins to the Maya PLE format as Autodesk/Alias doesn't allow for that.
I'm not familiar with the Blender API (it's python, right?), but someone who is should be able to write an exporter pretty fast, as the format is rather straight forward...
But regardless of the exporters, the viewer and loader would always work. So if there's someone here familiar with the Blender API he'd only have to write the exporter itself...
My plane leaves in two hours, so I've got to the get going, but I'll post the format specifications as soon as I'm back. (Maybe sooner if I find an internet caf
#93841 - Sausage Boy - Fri Jul 21, 2006 4:51 pm
parrot
That would be nice.
tciny
A shame... Not all people can afford Maya. Hopefully there is some Python hacker around here. Also, is there animation support in your format. That's almost a must-have, really.
How about integration with separate physics libraries? How do other 3d libraries handle this?
_________________
"no offense, but this is the gayest game ever"
#93842 - tciny - Fri Jul 21, 2006 4:56 pm
I know, yet on the other hand Maya is a very widespread tool for animation and with the move to that platform you also make it interesting for the more professional animators.
I really don't mean to say anything bad about Blender; but looking at the audience you'll find that Maya has the more professional user base...
So having an exporter for both packages would be very nice imho.
Yes, it features sekeletal animation. As posted in another thread, theres DSM files, which store the model and sekeleton data and then theres DSA, which stores animation data.
That way you can use one animation for multiple characters, blend between animations and so forth.
Talking about physics: As the format is joint based you could use it for ragdoll physics or procedural animation.
Imho it's a rather flexible format that takes up very little memory, but of course I'm interested in what you think about the concept.
I have to go now, but I'll keep get updated asap.
#93843 - parrot_ - Fri Jul 21, 2006 5:02 pm
Come to think of it, anyone new to 3D will need a free, simple-use editor. I suppose it might be possible.
Also, a feature list:
- MD2 model loading (apperently quite good)
- BMP/PCX/TGA texture loading
- Set of easy to use classes
- Easy to use functions
- (EDIT) Allow for attachable physics library (e.g. use your own physics library w/ the 3D lib, else go onto a default?)
_________________
Squak! etc.
My Blog
#93845 - Sausage Boy - Fri Jul 21, 2006 5:04 pm
Sounds great! I do not doubt that Maya is a better tool, but I too would like to be able to do little models. The best solution is of course, as you say, to make two versions, if possible.
_________________
"no offense, but this is the gayest game ever"
#93868 - josath - Fri Jul 21, 2006 7:16 pm
here's my suggestions on what kind of functions I think would be useful.
global funcs
init3d()
setViewpoint(x,y,z,xrot,yrot,zrot,FOV)
update3dobjs()
class Object3d
load(model_data)
setVisible(true/false)
setPos(x,y,z)
setRot(x,y,z)
setScale(x,y,z)
isCollidedBBox(object3d) // only checks bounding obx
isCollidedPoly(object3d) // checks if any polys are touching
gotoAnimFrame(int frame)
playAnim()
stopAnim()
and perhaps a few primititves as well:
cube, sphere, cylindar, pyramid, cone, torus, teapot
That all extend object3d, except you don't need to call load(), they already have built in model data representing the simple primitive. This way we can mock up 3d games without having built all the 3d models yet.
Question about scenery (level geometry, like floors and walls) , can you load the whole thing just like a regular model, or does it need to be handled differently? if so, may need an additional class for this:
world3d extends object3d
loadWorldData(world_data)
// anything else needed here?
----
honestly, the above functions, plus an easy way to get model data out of a standard 3d format (ideally a commandline converter app which reads in a standard 3d format, which blender, maya, 3ds max, etc can all save to)
and these are all you'd really need in order to start seeing a lot more people make 3d homebrew.
#93871 - Sausage Boy - Fri Jul 21, 2006 7:30 pm
I'm really no 3D guru, I've just happened to do some little experiments with display lists and lots of libnds source code reading.
Your interface looks really nice. Perhaps collision detection is better in another library? I don't know how well existing physics libs translate to the DS, they probably use tons of floating point math. Would a typedef to a fixed class fix the problem, or is a major rewrite required?
Is it up to the library or to the user to manage all the Object3d's? update3dobjs(); at least would need some kind of reference to all the objects.
_________________
"no offense, but this is the gayest game ever"
#93944 - josath - Sat Jul 22, 2006 1:57 am
| Sausage Boy wrote: |
| Is it up to the library or to the user to manage all the Object3d's? update3dobjs(); at least would need some kind of reference to all the objects. |
Either way would probably be fine, if it's not automatic in the library, it's trivial for me to just make my own updateAll() func which just loops through all my object3d's (which i store in a vector or somesuch) and calls update on each one.
If i can know the x,y,z,width,height,and depth, I can very easily do bounding box collision detection, so this doesn't necessarily need to be in the library.
It's just the per-polygon detection which I would need to know more about how the 3d works internally in order to calculate, and that seemed good to include into the library. Thus I just put the other func in with this one
#93985 - parrot_ - Sat Jul 22, 2006 8:34 am
Oh, for vars such as x, y, z shouldn't the be functions like:
SetZ(z)
SetX(x)
SetY(y)
GetZ(z)
GetX(x)
GetY(y)
in the Object3D class
_________________
Squak! etc.
My Blog
#94147 - tciny - Sun Jul 23, 2006 11:47 am
I think the API you propose generally goes in the right direction, as it doesnt require the user to know anything about the DS' inner workings, but I'd try to take it back at some points to allow for greater flexibility.
I'll post some of my thoughts in about two days when I'm back home. :)
#94296 - Valmond - Mon Jul 24, 2006 8:19 am
Little question, would the skeletal anims support several bones per triangle (assuminag already no blending, ie. only one bone per vertex) ?
I wrote a XFile-> 'my DS format' converter, but it does just static meshes, it
would be really nice to have a real standard though (and animation, miam !).
/Valmond
_________________
N?fer & LudLib
#94297 - parrot_ - Mon Jul 24, 2006 8:38 am
What? I thought we were doing MD2 style models.
_________________
Squak! etc.
My Blog
#94323 - tciny - Mon Jul 24, 2006 11:32 am
I initially wanted to support soft skinning, but it'll have to wait as I'm currently trying to get a basic format working. It's planned flexible enough that features like this can be added later on though.
So right now it's rigind bindings only as they're a lot faster to solve.
Concering MD2 models:
The central problem with formats like MD2 is, that they store the whole mesh for each keyframe. On the one hand, this makes solving the vertex positions for any given time rather easy as you dont have any hierarchies and so forth, but on the other hand it takes up a whole lot of memory, is totally unflexible (you cant change the position of a limb with code; so no ragdool, procedural animation and so forth) and forces animators into creating as little keyframes as possible.
Thats why i strongly favour skeletal based approaches. They're a tad slower most times but give you more flexibility, save a huge amount of memory and will give you more sophisticated animations most of the time.
#94347 - tepples - Mon Jul 24, 2006 2:04 pm
But isn't it easier to animate convincing loose clothes with the MD2 approach than with the skeletal approach?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#94351 - tciny - Mon Jul 24, 2006 2:41 pm
If you mean in the sense that you can just physically simulate cloth and then bake it to vertex transformations, then yes, that's something that MD2 is better at.
On the other hand, phsical simulations are hardly ever loopable, and getting enough keyframes for a convincing movement would mean storing such a great number of keyframes that there's hardly anything left besides it.
Skeletal animation would offer you to use a number of bones on the most relevant positions of the cloth object and let your animator control them directly. Or, alternatively, you could physically simulate the movement of the bones and export that.
Though, to be honest; if you really want physically simulated cloth I'd propably suggest really solving the physics on the DS. If the object doesnt have too much vertices it should be possible to pull it off without too much of a slowdown...
Say you have the user controlling a character, then the cloth should (for a realistic result) be influenced by things like a sudden change in direction. This is not the case with precached simulation data.
So in that sense I'd say the most effective approach would be to create a number of bones in the cloth object and then solve the position of the joints using a physical simulation on the DS. That way, you only need to integrate the physics for a very small number of points (you could propably even fake it in most cases) and still get a good approximation...
or at least thats my opinion :)
#98926 - Erith - Fri Aug 18, 2006 3:45 pm
I saw that on the Devkit toon_shading example is attached a statue.bin file, and it seems to be the model... How to convert to this format?
#98994 - Lick - Fri Aug 18, 2006 11:46 pm
Bin files can be formed in any 'structure'. THey are just binary data, often WITHOUT any header info or similar identifying properties.
Check out what kind of loading-procedure the example follows (like load vertex XYZ then load texco UV) and write an exporter for your favorite 3d modelling application to export to that format (vertex XYZ texo UV).
Write in binary mode.
_________________
http://licklick.wordpress.com
#99002 - dovoto - Sat Aug 19, 2006 12:19 am
I seem to remember mike telling me they were display list formatted. Display lists are just packed 3D commands and there are macros in libnds to create them.
I think toon shading just uses a lookup table to determine the shade and it indexes into that table using the red component of the lit pixel....this is from memory of a while back though.
_________________
www.drunkencoders.com
#99500 - josath - Tue Aug 22, 2006 2:07 am
So whatever happened to our grand plans of an EZ 3d wrapper?
#99597 - Sausage Boy - Tue Aug 22, 2006 4:34 pm
Well, tciny didn't finish his exporter of course! :P It's not like I am lazy or something... ;)
I'm actually working on a texture converter, it's necessary to get all the tools and file formats sorted out before we start making them easy to use (I'm not entirely sure who 'we' are yet, though).
Ogre uses Blender with some export scripts to get its data, I figured we could do the same. Any Python guru's out there? Take a look at BlenderExport and BlenderSceneExporter, together with a texture converter that should be all we need to get nice 3d on the DS with free tools.
THEN we'll be able to make a nice lib :P
_________________
"no offense, but this is the gayest game ever"
#99604 - Erith - Tue Aug 22, 2006 5:30 pm
Yeah nice, But I still think that a FBX => DS importer would better.
Because FBX is an universal Format and it's supported by all the professional 3d package. it supports Uv coordinates, skinning(with influences) and bone animation... For me is too hard to make someting so difficult because i'm a newbie in programming (But I'm enough expert in 3d graphic).
#99605 - josath - Tue Aug 22, 2006 5:32 pm
| Erith wrote: |
Yeah nice, But I still think that a FBX => DS importer would better.
Because FBX is an universal Format and it's supported by all the professional 3d package. it supports Uv coordinates, skinning(with influences) and bone animation... For me is too hard to make someting so difficult because i'm a newbie in programming (But I'm enough expert in 3d graphic). |
Is it supported by the free 3d packages as well? I think most people in DS homebrew are not going to pay $100s for a 3d tool just to make a homebrew 3d game.
#99618 - Erith - Tue Aug 22, 2006 6:39 pm
The free version of Daz3d Support FBX! ;-D
#99628 - Sausage Boy - Tue Aug 22, 2006 7:20 pm
While I do agree that a converter from a specific file format would be better, as it would allow you to choose any modeling software without writing an exporter for every one, I'm a little worried about level designing, placing models and spawn points and barrels and design a level. Apperently Blender has some support of this, as Ogre uses it. Is there any widely used file format that does this?
_________________
"no offense, but this is the gayest game ever"
#99630 - dXtr - Tue Aug 22, 2006 7:28 pm
what about just making a "COLLADA to ds_compatible_format" converter? many modeling packages seems to have support for COLLADA (including blender)
_________________
go back to coding and stop screaming wolf :)
#99637 - Sausage Boy - Tue Aug 22, 2006 9:19 pm
COLLADA seems like a nice option, I'm looking at it as we speak. Ok, I admit, actually I'm going to bed, but I looked at it before speaking. Or writing. It appears to be fairly simple to parse and well supported.
_________________
"no offense, but this is the gayest game ever"