Skip to main content
GameDev.net gamedev.net
🔒 Locked

Modeling over Shell tool

Started by enunes Jun 9, 2010 at 11:19 PM 10 replies 2k views
Original Post
enunes
enunes

Issue: I'm a programmer, not an artist. As such, I tend to use what is called "programmer art" on my graphics programs. My "games" are just a hobby, though. (
).

Issue #2: I hate modeling programs due to the complexity to learn and their dependancy on the mouse. I also tend to think they are too "analogic", eyemeter-based, and I want simple models.
I like scripting and automation. I am an Arch Linux user and as such, I like to "keep it simple" (and minimalist). Finally, I live my life in a terminal window running vim, g++, make, etc.

Issue #3: I'm a beginner in game development (not in programming neither C++, though), so I tend to use just some static geometry and I focus on learning game mechanics rather than graphics techniques.

I used to design my models by hand using an own file format (something like .obj, but easier to parse).

I always wondered how far a shell (terminal, console, black window, prompt, name it) based "modeler" for simple static geometries would go.


Today, I just had it and wrote a small application for that. I called it MooSh (Modeling over Shell) and after a couple hours of code it can already export cube based geometries. For example, I give it the left-low-far coordinate and the right-up-near coordinate and it adds to its internal data structure with vertex arrays: the vertices, normals, texcoords and triangles necessary for a cube with those points. I can add as many as I want.

The "draw"/"render" command takes what I have in that database and pops a window containing the current model. I can fly around the model, finally, using the mouse. But no edits are allowed on the graphic window.

http://img823.imageshack.us/img823/4895/moosh02.png

I can also do basic stuff: clear the model, write the model to another file, name the model. As I use the standard input, I can also pass a textfile containing the instructions to generate that model and it will run just well. (like a textfile containing: name unit_cube new cube -0.5 -0.5 -0.5 0.5 0.5 0.5 save unit_cube.model exit). Users could just exchange those scripts and everyone is good.

Next improvements would be to add more simple geometry options (spheres, cylinders, etc) and maybe a better structured data structure as this one is rather sketchy. Maybe being able to add models one made before, thus adding the possibility to "create new basic models".

So, to the point of creating this thread:

1) At least to me, I believe I came up with that concept myself. Is there already work following this concept?
2) I suppose things cant get easier than this for generating simple models based on combination of simple geometry. Do you think there would be users (a few maybe) interested in something like this I refine it and share it? (for example, if I add the option to import/export .obj files instead of my own local format).
3) Do you think it is possible to refine this idea to a point where it could still be simple and generate some useable content?

Well I want some suggestions and comments. If you think this effort is useless, please let me know it and why you think so :)

Thanks in advance!
Nypyren
Nypyren
1) The concept reminds me a little of POV-Ray.

2) I don't know. I got fed up making hardcoded models in my programs and started learning XSI Mod Tool. I like being able to see what I'm working on immediately as I'm making it. POV-Ray had brutally slow iteration time where I would tweak a number, wait a minute for render, tweak it again, repeat.

3) Possibly. How complicated do you want to make it? Complicated enough that it needs its own language? You could probably reuse an existing declaritive/functional language pretty easily.
enunes
enunes
Yeah in fact the first idea was to have editing and seeing interactive. As this is a prototype, it currently just calls another program of mine which displays the model (in fact it exports a file with the current database and calls the drawer with that file) that's why I have the render command. A next step would be to use a gui library and add an input line and a GL widget.

The point is to eliminate input through drag and dropping geometry and menu browsing. It would be perfect if I could achieve a way of creating the models without having to deal with those.

Any other thoughts?
Captain P
Captain P
#1. This concept reminds me of the demo scene. People writing insanely small applications containing rather impressive environments. They just have to generate geometry to keep things small.

#2. Perhaps. Probably not a lot, but you never know.

#3. Depends on what you define as usable. ;)


Now, if I would do something like this, I'd probably write a Python module. I would make a distinction between generating the geometry and exporting it, so plugging in a new exporter would be relatively easy. This is more or less the kind of interface that I would work towards:

import geometrycube = geometry.Cube((50, 10, 30), (30, 20, 15))cube.translate((0, 0, -30))cube.scale((1, 1, 1.4))sphere = geometry.Sphere((0, 0, 5), 15)sphere.material = geometry.Material('test.png')sphere.color = (255, 255, 0, 127)geometry.objexporter.export([cube, sphere], 'test.obj')customExporterFunction([cube, sphere], 'custom.cst')

You can write your own format, of course, but using an existing scripting language is easier to implement and being able to use a familiar language eases the learning curve.
Emergent
Emergent
One way to get the best of both worlds could be with a traditional modeler + integrated scripting language (Python, lua).
Antheus
Antheus
Quote:
At least to me, I believe I came up with that concept myself. Is there already work following this concept?


On PC, Autocad had this in 1982. It has kept command prompt as integral part ever since. In addition to command line, it originally used variation of Lisp as well for complex task and advanced interaction. It's possible to write full-blown applications using nothing but. They added a ton of other languages since then.

Other CAD packages typically support same.

Original modeling programs before then were command line based as well, but for serious work light pens and various analogue displays were used, since it interactivity was crucial.
enunes
enunes
Quote:
Original post by Captain P

Now, if I would do something like this, I'd probably write a Python module.

...



You are right, I am more interested in the environments rather than the geometry.

That example target description looks awesome. It is somewhat I'm trying to accomplish.

I do know some python, I use it for automating some file tasks in some other programs (for example, to generate some formatted random input file to analyze optimization algorithms results). I also used it to generate some other geometry. For example, I passed some f(x) to it and it rotated the function around the Y axis, generating some volume used as geometry, I believe some modeling programs do that too.
Though I never really worked anything more 'program like' on it, just some scripts for things like those.

I might take the time to learn it though, as Emergent also enforces that. It's probably more worth learning how to write a proper python module than inventing a new "language". I know some lua too, but used it only a day or two and I like python, so I might stick with python.

Quote:
Original post by Antheus
On PC, Autocad had this in 1982. It has kept command prompt as integral part ever since.

...



Indeed I hadn't considered that. :) Makes enough sense.


Thanks for the input!
enunes
enunes
Quote:
Original post by theOcelot
Lua has a simpler, slightly cleaner syntax, is easy to write, and is dead simple to embed. Just saying. [smile]


Alright, I'll take the advice :P

I have a question then. My impression of lua is that it is more for automating stuff such as shell. I have always used python with an impression it was designed with scientific and prototyping in mind. My choice over python is influenced by its huge base of math and scientific content. Basically everything I needed in that matter was there (for an example, fourier transforms for some disciplines).

How would you compare Lua to Python in terms of math/scientific content availability?
theOcelot
theOcelot
I'm not sure about that. Lua is certainly not suited for shell automation stuff; its philosophy is one of rock-bottom minimalism, which includes only a bare minimum of OS stuff, and even that is optional. That's part of what makes it so nice to work with.

I'm sure there are libraries out there that include all that math stuff in Lua though, and even if you can just get it in C, it's not too hard to export it to Lua yourself. I thought I saw a list somewhere of advanced math libraries for Lua, but I can't seem to find it now.

I suppose in your case, Python might actually be a better choice, for the reasons you mentioned. To be honest, the math requirements hadn't occurred to me.
RobotGuy
RobotGuy
Have you looked at BRL-CAD (http://brlcad.org/)? I haven't actually used it yet but that is only because I haven't had time yet.

It appears that it is a Constructive Solid Geometry system that allows you to build up a model by using one command line application that accepts a set of scripted commands then you can export the model into a number of different file formats with a different tool.

Even if you don't like the actual scripted commands for the MGED tool, it would be a lot easier to create a python or lua package that would generate the MGED script from a set of commands than it would be to do CSG from scratch.
enunes
enunes
Quote:
Original post by RobotGuy
Have you looked at BRL-CAD (http://brlcad.org/)? I haven't actually used it yet but that is only because I haven't had time yet.

It appears that it is a Constructive Solid Geometry system that allows you to build up a model by using one command line application that accepts a set of scripted commands then you can export the model into a number of different file formats with a different tool.

Even if you don't like the actual scripted commands for the MGED tool, it would be a lot easier to create a python or lua package that would generate the MGED script from a set of commands than it would be to do CSG from scratch.


Interesting, thanks for the input!

I downloaded, compiled and installed the package (Linux version). My first impression is that it is highly overkill for my purposes. There are tons of apps in the package. I checked some manpages, some tutorials. It seems like a lot of stuff to learn for my humble purposes.

So, I will probably just stick with developing it myself. And after I get some results and some more complexity with it, I can share it along with a manual and examples, in case someone looks for a really simple modeler.

Also, I will take the opportunity to learn a bit more, developing it myself :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.