3D with xTalk Graphics

[xAction]

3DCube_Basic.oxtStack

(23.63 KiB) Downloaded 22 times

3D_Cube_Basic.png (60.55 KiB) Viewed 356 times

Let's start with the basic cube and a simple concept: Everything in 2D can be extruded into 3D with math. A simple rectangle can appear to be a floor , ceiling, or a road into vast desert plane simply by distorting it's corners, without any additional forms. The brain does the rest of the work at completing the illusion. A simple rectangle extruded into 3D space with the help of a few additional lines becomes a cube, of course.

The code is in the stack script.

This is how the cube is defined:

on InitCubeCoordinates
--- "I" = the distance of the vertice from center, ie, pivot
put 60 into I
--- X
SetX 1,I
SetX 2,I
SetX 3,I
SetX 4,I

SetX 5,-I
SetX 6,-I
SetX 7,-I
SetX 8,-I

--- Y
SetY 1,I
SetY 2,I
SetY 5,I
SetY 6,I

SetY 3,-I
SetY 4,-I
SetY 7,-I
SetY 8,-I

--- Z
SetZ 2,-I
SetZ 6,-I
SetZ 6,-I
SetZ 8,-I

SetZ 1,-I
SetZ 3,-I
SetZ 5,-I
SetZ 7,-I
end InitCubeCoordinates

Look Ma, 3D!

The SetX, SetY, SetZ are handler commands like this:
---- get or set values in custom property arrays

on setX n,tval
put the xArray of of stack (the mainStack of this stack) into tArray
put tVal into tArray[n]
set the xArray of of stack (the mainStack of this stack) to tArray
end setX

Nothing too fancy there, just puts the data in an array stored in the stack file.

The CUBE_LOOP handler is where all the action happens, but it's 159 lines long give or take a few empty lines, so dig into the stack script if you dig 3D graphics.

A full tutorial on how this works is available at Skytopia where the code originates, I just make it xTalk

[xAction]

But wait, there's more. Not sold in any store, real live 3D primitives in assorted fruit flavor colors!
Extrusion is basically just copy one thing, move it, draw lines to the matching points.
A cylinder is just an an extruded circle, or a polySided regular styled graphic in our case.
A cone is just a cylinder with the extruded points converged.
A sphere on the other hand is a circle foreshortened, duplicated, and rotated to create the appearance of a 3D...bunch of hoops really, but for our purposes it's sphere.

3D_Primitives_Basic_v7.oxtStack

(54.14 KiB) Downloaded 21 times

3Dprimitives.png (142.38 KiB) Viewed 351 times

[OpenXTalkPaul]

Wow, this is great stuff!
It reminds me of a few different demos I've seen, something similar to this was actually done with HyperCard back in the 90s. Of course it couldn't possibly look as good as this due to limitations of HC engine.

There was also some guy in the LC open source community that translated some code from another language ('R' I think it was) that even could pull in .OBJ files and rotate them and such. I'll have to dig that out and repost it here. It was crazy-impressive to do pretty with xTalk script + classic graphics controls.... That was fast for scripting but was no where near 'real time' rendering.

For fast (enough) or (near) realtime rendering, I was thinking it would be great to find a library that can use the GPU to render OBJ with texture/lighting and just give us back rendered image data that we can set an image control with (every x milliseconds), or maybe an extension that renders inside a widget, so then we can move the objects around on the card.

There was some sort of external (Franklin 3D I think it was called) that did some 3D stuff in RunRev back in the 2000s, but I never personally tried that so I don't know how it worked.

[xAction]

Yeah this kind of 3D wireframe thing goes way back to BASIC. I remember this guy from school blew my freakin' mind when he showed me a static 3D cube on his Atari 800. I had some code from a magazine but it required more pixels than my computer could handle...it almost looked like a cube, sort of.

I figure we should be able to pull off Battlezone, Red Baron, Star Wars Arcade clones with this level of generation, as soon as I can uncross my eyes and move the scripts from this demonstration to one that plays a game. It's not about xTalk as a game platform but just being a capable and versatile programming environment for now. The biggest step from "can it do x" to "yes!" is the attempt to make it do x.

R3D is the .obj file to xTalk convertor

I'm over here trying to convert an old BASIC procedural 3D space ship program to xTalk at the moment and now I'm thinking maybe I should just send a super low poly blocky ship out of blender and figure out R3D to do the heavy work. I'll just keep going til I hit another hard dead end.

I had Franklin3D on my machine for ages, but there was no documentation so I never made it do anything. It had a crazy price tag when it was available.

I got iGame3D working in LC 6 or 9.0.1 or something then it was dead after that. The code to talk to xTalk is still in the repository on SourceForge but I hit a bunch of errors trying to compile it and that's where I get stuck with most open source 'download it and build it yourself' projects.

That's why I was hoping to get RayLib working, it's modern, has a physics engine, is not abandoned and can be compiled from a text editor. Just read that old thread about RayLib and was totally lost. I thought for sure I'd understand what I was talking about in there, but nope, woosh right over my head. Maybe that week of coughing back in 2022 wasn't just a cough.

[richmond62]

R3D is the .obj file to xTalk convertor

Marvellous.

[xAction]

If this is your default view of the default cube in Blender extruded into a little winged thing

DefaultCubeShip.png (267.95 KiB) Viewed 315 times

Then use these export .OBJ settings (key ones are the axis, the rest probably ignored.)

R3B_Blender_object_export_Options.png (54.3 KiB) Viewed 315 times

With UP vector and all Rotations in the R3D stack set to 0 (or whatever value Left Most scrollbar position is) You'll get a match of your Blender viewport:

R3D.png (6.73 KiB) Viewed 315 times

[xAction]

Dissecting R3D:

A. import .obj file
r3d_load_OBJ loads an .obj file and stores it's vertices in an array: world[1]["model"]

world[1] is just one of near infinite number of models that could be stored...after we change things because:

set the curmodel of this stack to world[1]["model"]

Only holds one model in the stack properties, the rest would be floating around in memory in the world array and vanish when you restart the application or stack.

Let's look at a cube.obj file that R3D can read:

# Blender 3.4.1
# www.blender.org
mtllib cube.mtl
o Cube
v -1.000000 1.000000 1.000000
v -1.000000 1.000000 -1.000000
v 1.000000 1.000000 1.000000
v 1.000000 1.000000 -1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v 1.000000 -1.000000 -1.000000
vn -0.0000 -0.0000 1.0000
vn 1.0000 -0.0000 -0.0000
vn -0.0000 -1.0000 -0.0000
vn -0.0000 -0.0000 -1.0000
vn -0.0000 1.0000 -0.0000
vn -1.0000 -0.0000 -0.0000
vt 0.625000 0.500000
vt 0.375000 0.500000
vt 0.625000 0.750000
vt 0.375000 0.750000
vt 0.875000 0.500000
vt 0.625000 0.250000
vt 0.125000 0.500000
vt 0.375000 0.250000
vt 0.875000 0.750000
vt 0.625000 1.000000
vt 0.625000 0.000000
vt 0.375000 1.000000
vt 0.375000 0.000000
vt 0.125000 0.750000
s 0
usemtl Material
f 1/1/1 5/5/1 7/9/1 3/3/1
f 4/4/2 3/3/2 7/10/2 8/12/2
f 8/13/3 7/11/3 5/6/3 6/8/3
f 6/7/4 2/2/4 4/4/4 8/14/4
f 2/2/5 1/1/5 3/3/5 4/4/5
f 6/8/6 5/6/6 1/1/6 2/2/6

Parts of the .obj file:
Vertices (v): These are like the corners of a 3D shape. Each vertex has three numbers (X, Y, Z) representing its position in 3D space.

Normals (vn): Normals help define the direction a surface is facing.

Texture Coordinates (vt): These tell us how to map a 2D image (like a texture) onto the 3D shape.

Faces (f): Faces connect vertices to create surfaces. They define which vertices form a triangle or polygon.

Materials (mtllib and usemtl): Materials describe how the surface looks (like color, shininess, or texture). They’re linked to specific parts of the object.

Note the end of the .Obj file with the lines that begin with f and are loaded with slashes:

Let’s break down the first face line:

f 1/1/1 5/5/1 7/9/1 3/3/1.

Vertices (v):
Each number before the slash represents a vertex index.
In this line, we have four vertex indices: 1, 5, 7, and 3.

f 1/1/1 5/5/1 7/9/1 3/3/1.

--- The face connects the vertices (1, 5, 7, and 3) to form a polygon.

R3D isn't using the other properties but maybe some modifications could be applied based on the values if read.
Texture Coordinates (vt):
The number after the first slash (e.g., /1) represents the texture coordinate index.

Normals (vn):
The number after the second slash (e.g., /1/1) represents the normal index.
--- Everything in R3D faces away from the center of the object, toward the camera


My 'ship' design in the image above has Material properties like this:

usemtl Wing
f 26/40/2 25/39/2 27/41/2 28/42/2
f 30/46/8 31/48/8 32/50/8 29/44/8

Theoretically with some additional scripting we should be able to isolate those and make the materials allow us to modify the vertices in the IDE. For instance grab the 'Wing' vertices and apply scale or position adjustments to just those vertices to reshape the wing.
Each hideous line is just a rectangle polygon, however with how R3D draws things as a big pile of graphics, I'm not sure it will update everything under that modified polygon...we'll have to see.

[xAction]

I've modified the R3D stack to allow for multiple models to be loaded and accessed via menu.

R3D_02_29_2024.oxtStack

(522.87 KiB) Downloaded 12 times

R3D_MultiModel_001.gif (119.97 KiB) Viewed 305 times

I the .obj file loading button and the .obj picking menu call on r3d_chooseModel

on r3d_chooseModel aFile
--- reset all the sliders before loading or freaky things happen
resetallScrollBars
set itemDel to "/"
--- short name of file from obj model list menu
if number of items of aFile = 1 then
set the customPropertySet of this card to "OBJModels"
put aFile &".obj" into tModel
put the tModel of this card into world[1]["model"]
set the customPropertySet of this card to empty
else
--- long path to model file
put r3d_load_OBJ(aFile) into world[1]["model"]
--- 02-29-2024 save models into custom property
set the customPropertySet of this card to "ObjModels"
put item -1 of aFile into ModelName
set the ModelName of this card to world[1]["model"]
set the customPropertySet of this card to empty
end if
#salviamo il modello
set the curmodel of this stack to world[1]["model"]
#scale
put world[1]["model"]["scale"] into modscale
put 512 / modscale into dim
#save modescale
set the curscale of this stack to dim
R3D.scrollbardrag #this handler contains the render parameters and all the rest
end r3d_chooseModel

Since we are only viewing one model at a time we are storing it's data in world[1]["model"] and world[1]["model"]["scale"] , later that can be model[2]["model"], model[3]["model"] etc, right up until we hit a redraw speed bottleneck.

As you see in the gif the loaded files get stored in the cards' ObjModels custom property set.

I copied the "behave" button's script, which is the behavior of all the scrollbars, into the card script as R3D.scrollbardrag and call that directly from some scripts rather than sending a message to the button.
I thought "Okay all the scrollbars still work"....that's because they still use that button's script for a behavior.
Ultimately I want to get rid of all the scrollbars (and buttons) and get some models just moving, zooming by some other script-o-matic means.

I added a line to the render2 command to not draw a nasty green colorOverlay on the graphics, a bug that's been bugging me for a while.

Renamed resetAll to resetAllScrollbars just so there's no ambiguity about what it does, that script is in the stack script for some reason, and Ultimately I think the whole library should be in the stack script because otherwise the stack script doesn't know what you are talking about when you tell it to do some r3d_thing.

Next step is to get the render scripts to render to a group named after the current model or current model with a number index, instead of the single "r3d" group it uses now, so there can be more than one model active at once. Will also have to use a model index for those world[n]["model"] arrays. This should probably be already set up in that robot claw demo, which I didn't use because I assumed it'd be more complicated and I don't know what I'm doing yet.

I guess I should fork this and push changes on github? mmmaybe not just yet.

[OpenXTalkPaul]

If this is your default view of the default cube in Blender extruded into a little winged thing
DefaultCubeShip.png

Then use these export .OBJ settings (key ones are the axis, the rest probably ignored.)
R3B_Blender_object_export_Options.png

With UP vector and all Rotations in the R3D stack set to 0 (or whatever value Left Most scrollbar position is) You'll get a match of your Blender viewport:
R3D.png

SaWeet, looks like a Battlestar Galactica Colonial Viper if you make the snout a little longer Maybe could build 2.5D isomeric 'Defender' arcade genre game from this too.

[OpenXTalkPaul]

You could try using my 8 directional virtual stick Widget for controls, there are default scripts with it that contains a case/switch structure that can be used to script it.

https://github.com/PaulMcClernan/OpenXTalk-VirtualDPad

org.openxtalk.widget.8way.png (13.96 KiB) Viewed 247 times

Seeing this stuff again I'm wondering if some 3D controlling control or widget could be made, of the sort commonly seen in 3D tools (you know, those 3-axis arrows and perspective curved arrows around a little ball for moving / rotating 3D objects)

[xAction]

With some modifications to the scripts it definately could work like any other built-in control:

set vertices of the templateObjModel to objmodeldata
create ObjModel

Where ObjModel is type of control...an un-ungroupable group that contains the original vertice data whose properties modify it's 3D rendering. And the 3D properties changes would work just like changing width and height and location.

I'll try to get the scripts to the point where it almost looks like that's what's happening. Maybe a little inspector window clone is in order to figure out how it would all work.

[xAction]

R3D_03_01_2024B.oxtStack

(928.93 KiB) Downloaded 12 times

R3D_03_01_2024.png (43.13 KiB) Viewed 236 times

Updates!

• Stack "Scrollbars3D" added
• Handler resetAllScrollbars moved to that stack
• All scrollbars & buttons moved to stack "Scrollbars3D"
• MainStack Card script handler R3D.UseScroll3DProperties now manages all the 3D updates via the Scrolls3D custom property that is set by stack "Scrollbars3D" handler updateFromScrollbars
• MainStack now centers the "r3d" group in the window even with resize stack, woo!
• fixed some typos.
• Added a history field for keeping track of changes
• Added UNDO
• Set Postion scrollbars to range 0 to 4800
• set Focus Scrollbar to range 0 to 4960
• Set Translation scrollbars to range -800 to 800
• Set Scale scrollbars to range -0.001 to 4
• in r3d_inverse_m4 set detM to 0.01 if it reaches 0 to avoid bug
• in r3d_m4xv3 temp[ i ][ 1] & temp[ 4 ][ 1 ] set to 0.01 if 0 to avoid bug
• Moved the loading of OFF and PLY files from the buttons to the R3D card of mainstack, they store their data in the stack the same as OBJ files.

Think that's it for now.

[tperry2x]

I'm in awe of all of this. You are taking what I thought was possible with xTalk and turning it up to 11.

[xAction]

Someone much smarter than I did this 3D stuff, it's kind of bumming me out that I'm hitting my limits, there are things I want to make better but...it's math and that's my weakness. I'm just finally extracting it to a different state without totally wrecking it. Which I always had trouble with before. I seemed to have cleared my brain cache recently and have more space for new info, but only of a limited array depth.

[tperry2x]

I reach that limit regularly.
Frustrating when I know exactly what I want to achieve, but lack the capacity of actually doing it.

I've long wished for an additional memory module I could plug in
Or at least a processor upgrade.

[xAction]

3D Primitives now with at UV Sphere, as best as I could get it.
This with 8 "slices" and 8 "stacks", that could be increased but... it already looks like an abused cat toy.

3D_Primitives_Basic_v8_UVsphere.oxtStack

(97.95 KiB) Downloaded 11 times

Sphere3D_UV.gif (473.9 KiB) Viewed 165 times

Couldn't figure out how to close the loops, and struggled to remove the centroid.
it's loops within loops and when I told the program "if the numbers are this, then next loop" it was like "yeah, no, I'm not doing that, it's my ball and I'll draw lines where I want to"

I tried to do Z-culling but the current script can't handle that, it made some neat half melons though, and did some wild de-resolution things ...basically it was like this.
But I really just wanted to turn off the vertices that were farthest away so it rendered cleaner, but rendering happens in 2D where nothing is really far way. The 3D part is not generated in real time ....maybe that's what I have to do. hmmm,

Code was found here after getting all the wrong answers from ChatGPT and StackOverflow (is it ever anything other than?)
At least ChatGPT was able to turn some of the C/C++ mucky muck into something I could read.

Heh, the gif is almost 5 times larger than the stack.