New open-source frontier semi-clone
tom
It must be years since I posted to this newsgroup. Maybe 10 years ago I
did the 'yikesstation' Frontier fan site. More recently around 2006 I
was working on the reverse-engineered GLFrontier. After that project I
realised that there was no point working on proprietary, shambolic
disassembled code when a complete game could be written from scratch,
unencumbered by copyright issues, in less time.
So, starting in June 2008 I began writing a new Elite 2 style game from
scratch (with GPL license). It is called Pioneer, is written in C++,
SDL, OpenGL, works in Linux, Windows and whatever people can port it to.
So far me and 2 other programmers have worked on it, but now it needs
artists.
You can see screenshots and a docking video here:
http://pioneer.sourceforge.net/
The source code can also be downloaded by svn from the site, or from the
alpha 1 release:
http://tom.noflag.org.uk/pioneer/pioneer-0.alpha.1.tar.gz
Basically it needs lots of 3d models, identikit faces, more ships and
space stations, music and sound effects.
I'll see if I can get a windows binary up soon.
--
Tom
Brendan
Tom,
Contact the people making FFE3D. Maybe they will let you use some of
their art/model assets.
Nic
heard about it :)
Very impressive.
Secondly, you can't post that and not post a binary, that is a form of
torture most unkind.
http://nic.dnsalias.com/pioneer.zip (hope you don't mind)
Only tried it once so far, I took off from earth, flew to mars, then
hyperspaced to Ross 154 where I was eventually destroyed by pirates.
Felt just like the real thing.
Now to get it compiling in VS so I can fiddle with it in my normal
environment :)
Congrats and keep us posted on progress!
-Nic
tom
> Ok, firstly, Wow! How can this game be so far along and I not have
> heard about it :)
I didn't want to prematurely get people's hopes up. But now it is too
far on to *not* finish.
> Secondly, you can't post that and not post a binary, that is a form of
> torture most unkind.
> http://nic.dnsalias.com/pioneer.zip (hope you don't mind)
Hm. When Paul built it with MSVC the threaded terrain tile building
caused it to crash, but your binary has no problems.
> Only tried it once so far, I took off from earth, flew to mars, then
> hyperspaced to Ross 154 where I was eventually destroyed by pirates.
> Felt just like the real thing.
>
> Now to get it compiling in VS so I can fiddle with it in my normal
> environment :)
Maybe you can debug that nasty threading issue for me :)
You can disable threading in src/GeoSphere.cpp
> Congrats and keep us posted on progress!
I will do.
Can anyone draw nice control panel icons?
--
Tom
Nic
My build was compiled using MinGW, so I've just given the MSVC build a
shot to compare. I had no problems with a Debug build, but the Release
build gave me minor issues.
The reason for this were asserts on key bits of code. The first
example that caused an issue was assert(s_font = new FontFace
("font.ttf")) - In a release build the asserts and any code in there
won't run. So s_font ended up never getting set and that caused the
code to crash.
I haven't had any issues so far with the threading code on or off. But
i'll keep trying to see if I can replicate it :)
Thing I've noticed, but you probably already know about :)
* The ship Swordfish Starfighter does not exist (looking for model
"66") in the models.lua file, so this causes a crash if selected to
view in the ship purchasing screen
* The oval radar image does not show up on the HUD (haven't looked
into that yet)
* When leaving a space station during the docking sequence the walls
reappear and disappear (any clues as to why? I might try and debug
that)
Cheers,
Nic
Nic
> into that yet)
Ignore that - i'm an idiot :)
luke.d...@googlemail.com
Excellent work.
Just to share some info, the following packages were needed in Debian
to build it...
libglew1.5-dev
libsdl1.2debian
libsdl-gfx1.2-dev
libsdl-image1.2-dev
libsigc++-2.0-dev
Nic
Are you seeing the same problems with the shaders that I see? (I'm on
a GTX280)
http://nic.dnsalias.com/pi1.png (the lights at the top of the builders
being white squares (same happens for flashing lights on the ship
model)
http://nic.dnsalias.com/pi2.png (The clipping issue that occurs where
you can see space whilst inside the space station)
Do you know if is this is just being caused by the SBRE shader? Or is
there a bigger problem afoot? If you can point me in the right
direction I'll have a crack at trying to fix it if it's working fine
at your side.
Cheers,
-Nic
Phil Hibbs
Phil.
tom
> Hi Tom,
>
> Are you seeing the same problems with the shaders that I see? (I'm on
> a GTX280)
> http://nic.dnsalias.com/pi1.png (the lights at the top of the builders
> being white squares (same happens for flashing lights on the ship
> model)
Yeah this is a known issue. I added billboards to the model language,
and haven't bothered writing a glsl shader for them yet. Perhaps this is
a task for me this evening. hmmmm!
Press ctrl-s to toggle shaders on and off, by the way.
> http://nic.dnsalias.com/pi2.png (The clipping issue that occurs where
> you can see space whilst inside the space station)
Does this happen with shaders off?
I don't think i've seen this, but the docking code has been re-written
very recently and is probably heaving with bugs :)
--
Tom
Nic
> On 09/03/10 13:02, Nic wrote:
>
> > Hi Tom,
>
> > Are you seeing the same problems with the shaders that I see? (I'm on
> > a GTX280)
> > being white squares (same happens for flashing lights on the ship
> > model)
>
> Yeah this is a known issue. I added billboards to the model language,
> and haven't bothered writing a glsl shader for them yet. Perhaps this is
> a task for me this evening. hmmmm!
>
> Press ctrl-s to toggle shaders on and off, by the way.
>
> > you can see space whilst inside the space station)
>
> Does this happen with shaders off?
>
> I don't think i've seen this, but the docking code has been re-written
> very recently and is probably heaving with bugs :)
>
> --
> Tom
Hi Tom,
With shaders off all is well. The lights work ok and no issues with
clipping (or docking) whatsoever. With shaders on the clipping is
quite apparent, I've got a feeling it's not the docking sequence
itself, but just when SBRE shaded objects are drawn close to the
camera. The docking code seems to be all good as far as I can tell. (I
tried fiddling with the SBRE shaders, to no avail, no impact to
culling forcing your new R300 code or older versions, etc).
Let me know if you need any more info or testing. Or if I can help in
anyway :)
Cheers,
-Nic
tom
> Hi Tom,
>
> With shaders off all is well. The lights work ok and no issues with
> clipping (or docking) whatsoever. With shaders on the clipping is
> quite apparent, I've got a feeling it's not the docking sequence
> itself, but just when SBRE shaded objects are drawn close to the
> camera. The docking code seems to be all good as far as I can tell. (I
> tried fiddling with the SBRE shaders, to no avail, no impact to
> culling forcing your new R300 code or older versions, etc).
It will be due to a z-buffer hack used to allow planet rendering with
stuff sitting on the planet surface.
If you want to read up on this stuff here is a good page:
http://www.gamasutra.com/blogs/BranoKemen/20090812/2725/Logarithmic_Depth_Buffer.php
No nice solutions :(
--
Tom
Nic
and shader cleanup. I checked out all of your SVN log, you've been
very busy on this game for a long time! I admire your dedication.
Also, thanks for the link. That helps explains the z buffer code! I
really wasn't understanding it before that.
In that article it links to:
http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&reply_id=3513134
Which talks about using a similar method via gl_FragDepth to get
around issues where triangles sit behind the camera (like when we're
docked).
I tried it out and it seems to work well!
Firstly, I changed logarithmicTransform() to the same as his, then
for the frag shaders I made a new function:
void SetFragDepth(float z)
{
const float C = 1.0;
const float far = 10000000.0;
const float offset = 1.0;
gl_FragDepth = gl_DepthRange.near + (gl_DepthRange.far * (log(C * z
+ offset) / log(C * far + offset)));
}
(The gl_DepthRange addition is to take into account when we do our
zbias, etc jazz - not sure if that's the best/right way of doing it
though! (i'm guessing at least far should be passed from the C++))
Then I add a call to SetFragDepth to the end of all the frag shaders
(i.e. SetFragDepth(gl_TexCoord[6].z); ). Only issue was with
geosphere_sky (as that was already using TexCoord[6] so instead I pass
eyepos to the frag shader via a varying vec4).
Now all seems to work fine! No clipping issues and everything renders
ok. However, you probably know a million and one ways as to why this
is a bad idea and I just don't know what I'm doing :)
Here's the modified shaders I changed: http://nic.dnsalias.com/shaders_nic_mod.zip
I hope at least some of the above is interesting/useful, rather than
just a long-winded bit of text from a glsl noob.
Cheers,
-Nic
tom
> Firstly, thanks for the billboard shader (fixed the lights issue! :) )
> and shader cleanup. I checked out all of your SVN log, you've been
> very busy on this game for a long time! I admire your dedication.
>
> Also, thanks for the link. That helps explains the z buffer code! I
> really wasn't understanding it before that.
>
> In that article it links to:
> http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&reply_id=3513134
> Which talks about using a similar method via gl_FragDepth to get
> around issues where triangles sit behind the camera (like when we're
> docked).
>
> I tried it out and it seems to work well!
>
I'm a GLSL noob too. This is the first project I've coded that uses GLSL :)
I did implement the fragment depth thing, but found that it disabled
anti-aliasing on my driver. However, I'm using a different driver now,
and anyway incorrect rendering isn't good enough so let's go with this
patch ;)
I just committed it to svn.
--
Tom
Nic
I don't get AA unless I use:
SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, 1);
SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, 4);
Or similar - but then it seems to work fine.
One other tiny point of note:
In SystemInfoView::SystemChanged you call:
std::string _info = stringf(512, "Stable system with %d major bodies.\n
\n%s", majorBodies,
std::string(s->GetLongDescription()).c_str());
The 512 isn't big enough to hold your long description of Epsilon
Eridani, so causes a crash for me when I bring up the planets screen
of that system.
Also would the states of wheels_button make more sense switched
around? (add wheels down to 0 and wheels up to 1).
-Nic
Nic
I have uploaded a new binary, VS2008 compiled: http://nic.dnsalias.com/pioneer.zip
I have also made some very minor changes:
* Added Mouse Wheel Zoom to Sector, Galaxy, System View
* Increased mouse button array to encompass full mouse wheel range
* Fixed Model shader (wasn't compiling due to invLogZfarPlus1)
* Fixed issue of using asserts for critical function calls, replaced
with PiVerify
* Changed Undercarriage button to work oppositely (good? bad?)
* Can press Escape to return to game view from menu view
* Increased SystemInfoView LongDescription length to 2048
* Selecting a system from Sector view now also updates Hyperspace
target
All changes are in: http://nic.dnsalias.com/NicPatch.patch
I hope some of them might be useful.
Cheers!
Nic
tom
> Hi Tom,
>
> I have uploaded a new binary, VS2008 compiled: http://nic.dnsalias.com/pioneer.zip
>
> I have also made some very minor changes:
>
> * Added Mouse Wheel Zoom to Sector, Galaxy, System View
> * Increased mouse button array to encompass full mouse wheel range
> * Fixed Model shader (wasn't compiling due to invLogZfarPlus1)
> * Fixed issue of using asserts for critical function calls, replaced
> with PiVerify
> * Changed Undercarriage button to work oppositely (good? bad?)
> * Can press Escape to return to game view from menu view
> * Increased SystemInfoView LongDescription length to 2048
> * Selecting a system from Sector view now also updates Hyperspace
> target
That all looks lovely, except the undercarriage button thing. Buttons
like undercarriage and labels on/off show current state. Maybe the icon
should be changed so there is no arrow suggesting movement, ie
suggesting what the button will do rather than where the wheels are now.
Thanks for the patch (I have committed it), you are a diamond geezer
--
Tom
Angus
@g11g2000yqe.googlegroups.com>, nic...@googlemail.com says...
>
>
>
> The 512 isn't big enough to hold your long description of Epsilon
> Eridani, so causes a crash for me when I bring up the planets screen
> of that system.
Not a Babylon 5 reference in there by any chance? That is apparently the
system where the series was set.
Nic
Thanks for the commit :) In my infinite ignorance I had forgotten to
disconnect the new mouse button handlers in the deconstructors. Also,
the patch included one change I did which I forgot about (making it so
the player can't still fire when seeing the tombstone). But I added
that in the wrong place, so that's now fixed too:
http://nic.dnsalias.com/NicFix.patch
Apols! My testing was clearly not thorough enough.
Was looking through you model code. I like your skyscraper and
highrise models, you should uncomment them :) I tried my hand at
making some myself, but it's a painful process (for me at least) - I'm
very impressed at the ones you made as it's not easy to visualise. Any
there any tips or tools you use to help?
Also, are you adverse to including support for other model formats? As
mentioned in this thread the 3D models that accompany FFE 3D are
really rather good and would make a nice stop gap until we twist the
arm of a 3D modeller to make some for pioneer :)
Cheers,
-Nic
tom
<snip>
> Apols! My testing was clearly not thorough enough.
Nae bother pal, I have committed your fix.
> Was looking through you model code. I like your skyscraper and
> highrise models, you should uncomment them :) I tried my hand at
> making some myself, but it's a painful process (for me at least) - I'm
> very impressed at the ones you made as it's not easy to visualise. Any
> there any tips or tools you use to help?
Graph paper, but see below.
> Also, are you adverse to including support for other model formats? As
> mentioned in this thread the 3D models that accompany FFE 3D are
> really rather good and would make a nice stop gap until we twist the
> arm of a 3D modeller to make some for pioneer :)
Yes, last night I committed a basic wavefront obj format loader (works
best with obj files that contain normals). You call it from model static
functions like so: load_obj('some.obj') with a transform matrix as an
optional second parameter:
load_obj('untitled.obj', Mat4x4.new(v(2,0,0),v(0,2,0),v(0,0,2)))
would scale the object up 2x.
The .obj files themselves should live in data/models/, same place the
lua model definitions are.
Materials specified in the obj file are not loaded but materials of the
same name set with set_material() etc, will be used.
I agree making models from basic primitives is hard. The nice ship
models were all made by John Jordan, who wrote them for the original
bytecode model system, and then I ported them to the Lua model thing.
All the crap ones made of gray boxes are mine :)
I will have to consider how to do level of detail with external models.
It would be possible loading a different .obj for each detail level i
suppose.
--
Tom
Rhino
> Hi Tom,
>
> I have uploaded a new binary, VS2008 compiled:http://nic.dnsalias.com/pioneer.zip
>
Looks awesome guys! Nice work.
Nic
Although, I ran round in circles trying to add code to load the
textures too (if wanted, rather than just using colors from the
materials)
http://nic.dnsalias.com/3dmodel.png
Still needs a lot of work though on the shader side of things (turned
off in that pic for ease, intelligently setting gl_fragcolor depending
on whether it's got a texture or not is something I need to work
out :) )
-Nic
tom
Yes I had been pondering textures yesterday. They had been strictly a
post-v1.0 for me, since I always thought of the PC port of frontier,
with its swanky textures, to be heretical and somewhat blasphemous.
However, if artists are able to make models they will want textures... :)
The fairly clean way I thought of (which is a change to class
LmrGeomBuffer) is to change m_vertexBuffer to a plain vector of floats
rather than Vertex type (with point and normal). Then an operation can
be added like OP_DRAW_ELEMENTS that uses texture coords from the
m_vertexBuffer derived VBO, and overload SetVertex with texcoords too.
See 'struct Op': you can add the texture object ID to that.
But this means you need to pad the m_vertexBuffer with floats, since
billboards (point sprites) will be 3 floats, other textureless geometry
6 floats, and textured geometry 8. This will screw up glDrawElements
otherwise.
Alternatively, we could use different vbos for each vertex type. Dunno
how this works out performance-wise.
So how did you do textures? :)
--
Tom
Nic
So I added the code to the obj reader to read the "vt"s and then I
post those to an array of GLfloats with a s_curBuf->PushTexCoord call
for every SetVertex. There is also a new op code OP_SET_TEXTURE which
just holds a GLuint to the texture that gets loaded from the .mtl
file. That new op is pretty much just doing:
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, op.texture.tex);
The model FragShader takes a sampler2D and a bool to state the texture
and whether it should be used.
BindBuffers uses a new buffer array and ends up looking like:
void BindBuffers() {
glEnableClientState (GL_VERTEX_ARRAY);
glEnableClientState (GL_NORMAL_ARRAY);
if (USE_VBO) {
glBindBufferARB(GL_ARRAY_BUFFER, m_vertexBuffer);
glVertexPointer(3, GL_FLOAT, sizeof(Vertex), 0);
glNormalPointer(GL_FLOAT, sizeof(Vertex), (void *)
(3*sizeof(float)));
if (HasTexture()) {
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glBindBufferARB(GL_ARRAY_BUFFER, m_texcoordBuffer);
glTexCoordPointer(2, GL_FLOAT, 0, 0);
}
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER, m_indexBuffer);
} else {
glNormalPointer(GL_FLOAT, 2*sizeof(vector3f), &m_vertices[0].n);
glVertexPointer(3, GL_FLOAT, 2*sizeof(vector3f), &m_vertices[0].v);
if (HasTexture()) {
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2, GL_FLOAT, 0, &m_texcoords[0]);
}
}
}
I think the above is a pretty poor description :) But it gives you an
idea at least. I'll try to neaten it up and submit a patch so you can
see it clearly. Any suggestions for any different ways of doing it let
me know :)
The oolite models might fit the style a bit better than the FFE D3D
ones.....they all look good at least :)
-Nic
tom
Interesting plan. I think I can see a possible problem with it if used
alongside the regular primitive functions though. Indices into the
GL_TEXTURE_COORD_ARRAY have to match indices into the GL_VERTEX_ARRAY,
and if there is other geometry loaded before the .obj file then this
will break. Using a single vbo for vertices, normals and textures avoids
this problem. Previously I mentioned padding this array when changing
between 3, 6 and 8 float vertices (billboards, untextured, and textured
vertices). However, opengl VBO performance tips from smart people at AMD
and Nvidia usually say that your vertex size should ideally be multiples
of 32 bytes, which the textured vertices are.
So,
I suggest simply adding float tex_u, tex_v to struct Vertex, and when no
texturing is being used it can be considered padding. Overload void
SetVertex(int idx, const vector3f &pos, const vector3f &normal) with a
version that takes the tex coords too.
I still think that rather than having OP_SET_TEXTURE,
OP_DRAW_ELEMENTS_TEXTURED is a cleaner approach, and putting the texture
id into struct Op, and setting shader on OP_DRAW_ELEMENTS_TEXTURED. Then
there is no conditional in the shader also (although this probably makes
little difference for any reasonable GLSL 1.20 capable gpu... However,
let's see what works.
So yeah, I suggest adding tex coords to struct Vertex and in that way
using a single VBO. Otherwise, code to your own taste ;)
Thanks very much for joining the pioneer coding effort! I feel the
terrible weight of the project lifting off my shoulders :J
On 17/03/10 22:18, Nic wrote:
> Hmmm, well i'm not sure I've done it neatly.
>
> So I added the code to the obj reader to read the "vt"s and then I
> post those to an array of GLfloats with a s_curBuf->PushTexCoord call
> for every SetVertex. There is also a new op code OP_SET_TEXTURE which
> just holds a GLuint to the texture that gets loaded from the .mtl
> file. That new op is pretty much just doing:
> glEnable(GL_TEXTURE_2D);
> glBindTexture(GL_TEXTURE_2D, op.texture.tex);
>
> The model FragShader takes a sampler2D and a bool to state the texture
> and whether it should be used.
>
><snip>
Nic
VBO was easier than expected :) So that's all working well.
In the end I couldn't get it to work properly without the conditional
on the shader....it pretty much did (and it should do really), but
every now and then I'd see corruption. So i'm afraid that's still
there.
I removed OP_SET_TEXTURE and just extended OP_DRAW_ELEMENTS to have an
extra texture GLuint id. if it's -1 no need to bind the texture, for
everything else it binds and works.
All seems to work well and cleaner than my original implementation,
apart from one thing. The 4 lights around the docking bay when you
take off from earth. Only 2 are there that flash from the array of 4.
If I remove the first 2, then the two that are left appear (when they
weren't before). Really weird!
Once I get to the bottom of that I'll send a patch for you to
review :)
Oolite's ships are all under the GPL, so I'm hoping to get this
texture stuff done, then work out someway to make ShipType scriptable
from LUA then add in more ships that way :)
Although, ships aren't really high priority right now, so not quite
sure why I'm spending all my time on them - I'm guessing the autopilot
improvements are pretty high up there on the list for most
people......that looks tricky though, so may I may just leave that
alone :)
Cheers,
-Nic
Nic
m_vertices as a list of vector3fs, when now it isn't because it's got
the u & v components. One good hack deserves another, so I added a
stride to PutPointSprites....blurgh, i'll fix that later :)
Nic
Still a bit rough and ready, but gives you an idea of what I have done
at least.
http://nic.dnsalias.com/cobra3.zip if you want a model to try
(load_obj('cobra3_redux.obj',
Mat4x4.new(v(30,0,0),v(0,30,0),v(0,0,30)) *
Mat4x4.new(v(-1,0,0),v(0,1,0),v(0,0,-1))) works nicely enough)
Cheers,
-Nic
tom
> http://nic.dnsalias.com/NicTexture.patch
>
That looks lovely. Yes, the billboard vertex thing was a bit fishy.
I'll have a more careful pick over it tomorrow and probably commit.
--
Tom
Nic
send a patch for that too.
tom
> Cool :) I'll work on making the ShipTypes set up in Lua too and then
> send a patch for that too.
There is stuff in the ship types which could be put in the models. For
example gun mount positions. See how it is done for the space stations.
There is a function or two in LmrModel for querying arbitrary
attributes. This is used by space stations for angular velocity etc.
Model 'tags' could be used to indicate that something is a ship. See how
these are used for surface and orbital starports.
--
Tom
Nic
define_model in models.lua. e.g.
define_ship('Sirius Interdictor',
'interdictor',
{ 2*10^7,-2*10^7,1*10^7,-1*10^7,-1*10^7,1*10^7 },
4*10^7,
{
{ v(0,-0.5,0), v(0,0,-1) },
{ v(0,-0.5,0), v(0,0,1) },
},
{ 90, 1, 2, 8, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
90, 100, 16000000,
1)
Does that seem an ok approach? For ShipType::Type enum i've changed to
an std::string and in the code the hardcoded references are changed to
strings.
I've also added a load_lua function which traverses a directory and
loads all the lua there (even in subdirs (code should be portable, I
borrowed a win32 dirent.h/cpp from the LGPL Guile project). So at the
end of models.lua I added a call of load_lua('data/mods') and then I
have a 'cobramk3' directory in there that has the .lua,.mtl,.obj
& .png loads. I changed obj_load, mtl_load, etc to use a lua global of
"CurrentDirectory" to track which directory it should load from
(without having to do a chdir). All's working and seems good.
Does that sound like a good approach? I'm aiming it so people can just
add ships as drop in directories to keep things relatively clean.
-Nic
Nic
This patch moves the ShipType definitions out to Lua and allows other
ships and mods to be loaded easily.
With this patch applied http://nic.dnsalias.com/cobramk3.zip can be
unzipped to data/mods and will be add the cobra mk3 ship (has lights,
undercarriage roughly done, stats same as interdictor, so needs
modification).
Hope it's useful, it's a little rough, but might be a start. Should be
portable.
Cheers,
-Nic
tom
> http://nic.dnsalias.com/NicMods.patch
>
> This patch moves the ShipType definitions out to Lua and allows other
> ships and mods to be loaded easily.
>
> With this patch applied http://nic.dnsalias.com/cobramk3.zip can be
> unzipped to data/mods and will be add the cobra mk3 ship (has lights,
> undercarriage roughly done, stats same as interdictor, so needs
> modification).
Nice. Finally got round to applying it. I made some changes (putting
ship definitions into the model as attributes to avoid some dependency
issues with the model viewer, and make it more like the way space
stations are defined).
Note that GameMenuView.cpp also does some directory traversal and has
different win32 directory walking code. I should replace it since there
is opendir for win32 in your code.
The MSVC bits didn't apply cleanly :(
Cobra 3 looks very nice :)
I'm going to do some work on autopilot when I get the time. (New job, etc).
--
Tom
Nic
more ships to have as mods too :)
I'll check out the GameMenuView code, I did have a quick look for
already existing traversal code and must have missed it. D'oh!
Looks like good work on the autopilot code. I think bezier.h is
missing from SVN right now, so haven't tried it out yet, but will look
forward to it all when done :)
Congrats on the new job! Hope they don't work you too hard.
Cheers,
-Nic
tom
> Great! Your way was better and neater. I'll try and come up with a few
> more ships to have as mods too :)
>
> I'll check out the GameMenuView code, I did have a quick look for
> already existing traversal code and must have missed it. D'oh!
Yeah i should have shoved it in utils.cpp or something. But using the
opendir implementation you used makes sense
> Looks like good work on the autopilot code. I think bezier.h is
> missing from SVN right now, so haven't tried it out yet, but will look
> forward to it all when done :)
oops. I've just committed bezier.h now
> Congrats on the new job! Hope they don't work you too hard.
:)
--
Tom
gernot
check http://www.spacesimcentral.com/pioneer-f35/modeling-for-pioneer-t1009.html
for the progress of the model
thanks for your interest, i have to find someone who can explain me
the inner structures of pioneers models.
things like animations with solid models and the proper handling of
text (rotation) are not to clear to me,
also ship specs could be better explained (especially all the numbers
which stand for the initial setup of the ship, like nr. of gun
mountings and so on)
many i found out by try and error, but this is very time expanding.
btw, i assumed a scale for pioneer which is compliant to frontier,
where the initial vertex spacing is ~0.5m.
gernot
1m, sorry. but 10 times fe2
gernot
one ship, many variations. some might like a blue one, some a red/
green or crimson/yellow.
and suits to my original nfs4 models which textures are all grey and
you can specify color sets by alpha channel.
something i have to suggest for pioneer, one .obj many color(sets).
since alpha is not needet for transparency/illumination in pioneer (a
different model with different material).
maybe paint(colorize) your ship when purchase (like a car) would be
nice.
gernot
gernot
if they are very rough.
but will give us a set of 5 new ships in a short timespan.
- cobra mk1 (almost finished)
- lifter
- shuttle
- lynx
- panther clipper
i think i will make the raw .obj files accsessable for everybody soon,
so yours can work yourself on a fitting .lua script for them (and i
don't have to make it all myself "sweat").
allready they will be split up to several .obj to make it easy to use
for variable materials (matte, trans, variable0,1,2, default, etc.,
easy cause they have allready been made that way to fit nfs4 and make
texturize easier if you have separated objects for each texture/
material)
they all have grayscale textures to fit for colorize.
and i really would like to see something like the described alpha
channel use for color sets.
example, use range 0-63 for color1, 64-127 for color2, 128-191 for
color3, 191-255 for color4 (blending not necessairy but would be a
hit).
now by specify the color set used in the skin by alpha plus grayscale
of texture plus color var. you get stunning effects.
result ranges from a nightblue colored tanned ships to psychedelic
acid colors.
gernot
gernot
lots have become plain, but rotation is still a riddle (and you said
you did models in lua because of easy animation, i would have animated
up to ten models in this time in common CAD while i was struggling
with lua.
someone please hands me the proper solutions for rotating either a
called or loadet(solid) model, i was looking at how the clock was
animated, but i think there must be different ways to do the job.
anyways, i didn't found out how to transpose the rotation from a z
rotation to a x rotation, seems not to work for me, it allways dangles
to multiple sides.
might think i'm stupid, i don't mind, simple question, simple answer,
no big thing. not everybody feels common with lua and it's command
structure so please help (english is not my native language, and
reading the vast amount of documentations makes life boring).
maybe one of you developers could setup a small guide to commands used
in pioneers lua scripts, that would be nice and helpful for others too
(3d modelers usually don't understand programming much).
i know it's not heavy, scripting lua, but you can loose a lot of
hairs, if you don't know the right expression of a command, also you
can save a lot of wasted time having a comprehensive lua > pioneer
style guideline.
i hope someone answers at least ;-)
gernot
gernot
might not be a courier but a nice ship anyways (looks more like a
harrier, imo), can i get my hands on that model?