It still doesn't work, at all, I get no errors: just a nice black
(empty) scene :).
I will post the code when I get home later today.
As I said, I first want to get it to work: and the first step (in that
case) would be to update the entire vertex buffer every frame. I have
tried nothing more than that.
On Wed, May 28, 2008 at 12:34 PM, Michael Cummings
<cummings.michael@...> wrote:
> Are you getting an error, if so what is it, and provide a stacktrace?
>
> And it would help if you posted your changes as well.
>
> borrillis
>
> On Mon, May 26, 2008 at 5:30 AM, Jonathan Dickinson <jonathand.za@...>
> wrote:
>>
>> Hi All,
>>
>> I am trying to convert the current terrain manager to an editable one
>> (like the original ETM author did). I can't get to grips with the C++
>> code so I thought I would try myself.
>>
>> I have basically moved the (unsafe) routine in Init to a new method
>> (FillPositionBuffer) and I am trying to call it from every frame: if I
>> only call it once it works (i.e. not editable), but if I call it a few
>> times it failes (i.e. editable). I am calling it from
>> RenderVisibleObjects in the scene manager.
>>
>> What gives? All I want to do is to have the vertex buffer update every
>> frame so that I can follow the routine:
>>
>> Make it work -> Make it right -> Make it fast
>>
>> I created the buffer using a variety of BufferUsages (with no luck). I
>> have near identical code to the original (just split the tex coords
>> and pos loops).
>>
>> --
>> Jonathan
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> axiomengine-users mailing list
>> axiomengine-users@...
>> https://lists.sourceforge.net/lists/listinfo/axiomengine-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> axiomengine-users mailing list
> axiomengine-users@...
> https://lists.sourceforge.net/lists/listinfo/axiomengine-users
>
>
--
Jonathan

Are you getting an error, if so what is it, and provide a stacktrace?
And it would help if you posted your changes as well.
borrillis
On Mon, May 26, 2008 at 5:30 AM, Jonathan Dickinson <jonathand.za@...>
wrote:
> Hi All,
>
> I am trying to convert the current terrain manager to an editable one
> (like the original ETM author did). I can't get to grips with the C++
> code so I thought I would try myself.
>
> I have basically moved the (unsafe) routine in Init to a new method
> (FillPositionBuffer) and I am trying to call it from every frame: if I
> only call it once it works (i.e. not editable), but if I call it a few
> times it failes (i.e. editable). I am calling it from
> RenderVisibleObjects in the scene manager.
>
> What gives? All I want to do is to have the vertex buffer update every
> frame so that I can follow the routine:
>
> Make it work -> Make it right -> Make it fast
>
> I created the buffer using a variety of BufferUsages (with no luck). I
> have near identical code to the original (just split the tex coords
> and pos loops).
>
> --
> Jonathan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> axiomengine-users mailing list
> axiomengine-users@...
> https://lists.sourceforge.net/lists/listinfo/axiomengine-users
>

Hi All,
I am trying to convert the current terrain manager to an editable one
(like the original ETM author did). I can't get to grips with the C++
code so I thought I would try myself.
I have basically moved the (unsafe) routine in Init to a new method
(FillPositionBuffer) and I am trying to call it from every frame: if I
only call it once it works (i.e. not editable), but if I call it a few
times it failes (i.e. editable). I am calling it from
RenderVisibleObjects in the scene manager.
What gives? All I want to do is to have the vertex buffer update every
frame so that I can follow the routine:
Make it work -> Make it right -> Make it fast
I created the buffer using a variety of BufferUsages (with no luck). I
have near identical code to the original (just split the tex coords
and pos loops).
--
Jonathan

Yes, for the most part the OgreDotNet tutorials should worrk fairly well
with Axiom. You may need to adjust some attributes and method names but the=
y
should be fairly trivial. Same goes for MOgre.
On 5/15/07, Alberto Le=F3n <leontiscar@...> wrote:
>
> Hi, recently I was playing for Axiom. For one year I worked with
> OgreDotNet. When I was run the first Axiom basic tutorial It give me the
> impression that is like the OgreDotNet tutorial. And I want ask you if I =
can
> run OgreDotNet tutorials in Axiom Engine, because you don't put more
> tutorials.
>
> Thanks.
> Alberto Le=F3n
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> axiomengine-users mailing list
> axiomengine-users@...
> https://lists.sourceforge.net/lists/listinfo/axiomengine-users
>
>

Hi, recently I was playing for Axiom. For one year I worked with OgreDotNet=
.
When I was run the first Axiom basic tutorial It give me the impression tha=
t
is like the OgreDotNet tutorial. And I want ask you if I can run OgreDotNet
tutorials in Axiom Engine, because you don't put more tutorials.
Thanks.
Alberto Le=F3n

Hi,
Save over 50% on your medication
http://www.ledrx .com
Remove space in the above link
Riddle House and saw lights glimmering in its upper windows. Frank knew
at once what was going on. The boys had broken into the house again, and
judging by the flickering quality of the light, they had started a fire.

The Axiom team is proud to announce that we have finally been able to
provide the community with a download. Being the first in a series of
releases, this is your chance to make sure this will be a very stable and
useable release. Please take the time to download and work with it in your
projects. Of course, report any issues on the forums or the SourceForge
bugtracker you may have so they can be corrected before the final release.
We are planning to have an RC2 in two weeks time and a final release 2 weeks
after that.
There are four different packages available in this release; full, binary,
source and media. The full package includes all source and binaries. The
source package includes all source files, dependencies and build system. The
binary package has just the binary assemblies and dependencies in a ready to
run form. There is only one binary package for Windows/DX initially, a cross
platform SDL binary package will be added soon. The media package contains
the media folder and is a requirement for both the binary and source
packages. The media folder is much small than in the past as we have trimmed
a lot of the fluff from it. The files are available from the SourceForge
Release System.
This release has been codenamed 'hobbiton'. Now, those of you that have been
paying attention are going to ask 'I thought the next release was codenamed
'bree'? To quote one of my favorite non-LOTR characters, 'Let me
axplain...noh, there is too much, let me summup'. The bree branch was
started with some very large goals, updating to Ogre 1.06, .Net
2.0Collections, new Plugin System, and upgrade to MDX
2.0. After a year of development, we were nowhere near being able to
release, let alone have a compilable system. Even though we were progressing
on the goal of updating to OGRE compatibility, it was hard to gauge where we
were since the source couldn't compile. This produced several side effects,
one it was demoralizing to everyone who was contributing to the project as
there was no visible results, second the community tends to think the
project is dead because forward momentum is so slow.
I decided that with the beta of XNA Game Studio and the XNA Framework that
the community at large needed to know that Axiom was not a dead project and
that it is a very viable solution for XNA development (yes there is an XNA
renderer under way, I'll get to that ). It is still a good solution for
OpenGL and DirectX and will continue to be. However there is an obvious
opportunity to gain a lot of forward momentum by piggy-backing on the
newness of the XNA Framework.
So about a month ago, we backtracked and started development on hobbiton. We
came to the realization that it was going to be very difficult to get bree
to a relatively stable state. However we couldn't ignore some of the
advancements that had been made in bree. So we decided that the best place
to start was the last known revision to work reliably. This just so happened
to be the last release that leed had put out. After several weeks of search
out patches and fixing up bugs we now have a fairly stable code base to
release.
There are several things to note about this release, the biggest is that is
is essentially the same as 0.7.0.0 with some bugfixes and minor
improvements. That means that if you have been working with the SVN Head,
your code will break against hobbiton. We do apologize for this, but it will
be a needed step in order for us to make major leaps forward in a very short
time. By taking this step we have been able to get ALL the demos working on
.Net and Mono! So all of the namespace changes, most of the OGRE updates,
the plugin architecture, and other changes were not moved back into hobbiton
to ensure a nice fast stable release.
So what happens now? hobbiton will replace SVN HEAD after the final release
and bug fixes and minor updates will occur there. As for bree, it will be
rebased on the hobbiton source and all OGRE 1.06 updates reapplied. The
plugin system, updates to the math library and .Net 2.0 collections will be
researched for viability and performance. The OGRE updating will move on a
slightly different track however. Feature sets will be identified and
updated, this should allow us to make progress and keep the system building
and the demos running.
So what's all this noise about XNA? I'll attempt to answer your questions
about using Axiom and XNA here. First lets discuss the XNA framework. There
are two platforms for XNA, Windows and Xbox. The Xbox platform is not yet
available, which is good, because there are some heavy requirements in order
to run on it. For the Windows platform we are already working on a
PlatformManager and renderer for the XNA Framework. There is no completion
date for this yet, but it is a priority. There are some technical hurdles to
overcome, the biggest being XNA does not have a fixed-function pipeline, so
Axiom's fixed-function pipeline needs to be converted to the equivalent
shader model. Doable, but tedious. For the Xbox, we have the same issues as
for Windows, plus there is no support for P/Invoke, which basically means we
can't use DevIL. So in short, Windows XNA will be available in the short
term, with minor changes to the base code. However, there will be a longer
and more intensive development effort to support the Xbox platform.
So enjoy this release and let us know if there are any issues, we'll get
them corrected as soon as possible!
The Axiom Team
http://axiomengine.sf.net

Aleks,
1) I am going to make the assumption you are working on the trunk.
2) Which dev enironment are you working with? VS.NET, nAnt, or #Develop?
3) The current version of MDX 2.0 that Axiom is known to compile with is
April 2006.
4) if you paste your build log to axiom.pastebin.com I can help you more.
On 6/19/06, aleks@... <aleks@...> wrote:
>
> Hello, Michael or Borrillis,
>
>
> Help me please to compile Axiom:
>
>
> My problem in Managed DirectX .Net 2.0
>
>
> I have only several compile errors and all it in
>
> RenderSystems-DirectX9 Project, for example
>
>
> LightType type hasn't Point
>
> LightType type hasn't Directional
>
>
> etc...
>
>
>
> And my file "C:\WINDOWS\Microsoft.NET\DirectX for Managed
> Code\2.0.900.0\microsoft.directx.dll"
>
> realy has empty LightType...
>
>
> I tried to setup
>
> dxsdk_jun2005.exe
>
> and
>
> DirectX_9c_Feb06
>
>
> and others versions of DX, but the file 2.0.900.0\microsoft.directx.dll did not be changed.
>
>
> Where I can get right MDX.dll .NET 2.0 ?
>
>
> Can you just send my this file?
>
>
> Thanks.
>
> Aleks.
>
>
>
>
> >
>
> Today, I committed a major change to the code base on trunk. This change
> eliminates the dependency on an external Math Library. Unfortunately, this
> will have an effect on all current applications out there. Hopefully this
> will not be a major detraction as it comes so fast on the heels of the
> switch from RealmForge.Utility to DotNet3D.Math. The classes remain the
> same and the namespaces are very similar.
>
>
>
> So to wrap up:
>
>
>
> Namespace changes
>
>
>
> DotNet3D.Math is now Axiom.Math
>
>
>
> Filesystem changes:
>
>
>
> The classes in Axiom.Math are physically located in the Engine\Math
> directory.
>
>
>
>
>
> Thank you for your continued support.
>
>
>
> Borrillis
>
>
>
>
>
> _______________________________________________
> axiomengine-users mailing list
> axiomengine-users@...
> https://lists.sourceforge.net/lists/listinfo/axiomengine-users
>
>
>

Today, I committed a major change to the code base on trunk. This change
eliminates the dependency on an external Math Library. Unfortunately, this
will have an effect on all current applications out there. Hopefully this
will not be a major detraction as it comes so fast on the heels of the
switch from RealmForge.Utility to DotNet3D.Math. The classes remain the same
and the namespaces are very similar.
So to wrap up:
Namespace changes
DotNet3D.Math is now Axiom.Math
Filesystem changes:
The classes in Axiom.Math are physically located in the Engine\Math
directory.
Thank you for your continued support.
Borrillis

Just wanted to send out a quick note giving some details on the projects
progress to date. Some of you who have been watching the commit mailing
lists have seen some activity lately, but for those who don't we didn't want
to leave you in the dark. We realize that things have been a little quite
lately on these lists, however that doesn't mean we aren't working.
Recent Changes
- Two branches were created for working on specific tasks
- DotNet3D_Integration
This branch was created to allow us to work with the new
DotNet3D library and integrating it with the current Axiom code
base. This
branch was recently merged back into trunck and the
RealmForge.Utility library is no longer needed. Prebuild files
have been updated and the NAnt build files will be updated shortly.
- bree
This branch was created to manage the task of updating the Axiom
code base to OGRE 1.06 compatibility. Any work on that task is
being committed here and will be merged back to trunck occasionally
- RealmForge.Utility dependency removed.
As part of the DotNet3D Integration, the RealmForge.Utility assembly
and namespace have been removed infavor of the DotNet3D.Math library.
More is going on every day, and we are hoping now that a major hurdlw is
past us that you will see more on these lists and forums from here on out.
Many thanks for all your support.
Borrillis